AADSTS90002: tenant identifier is neither a valid DNS name, nor a valid external domain

[doug-fitzmaurice-rowden]

When sending through my credentials as expected I got the following error:

tls {
    dns azure {
        tenant_id f837e147-205f-4bdf-9cfe-d07587a9ae3c
        client_id fe95b136-687a-4a86-ac38-dccae7ae32fa
        client_secret hunter2
        subscription_id 0f63fc1a-b8fc-4f0f-b401-e84305428a29
        resource_group_name dns
    }
}

[mynewdomain.example.org] solving challenges: presenting for challenge: 
adding temporary record for zone example.org.: azure.BearerAuthorizer#WithAuthorization:
 Failed to refresh the Token for request to https://management.azure.com/subscriptions/0f63fc1a-b8fc-4f0f-b401-e84305428a29/resourceGroups/dns/providers/Microsoft.Network/dnsZones/example.org/TXT/_acme-challenge.mynewdomain?api-version=2018-05-01: StatusCode=400 
--
Original Error: 
adal: Refresh request failed. Status Code = '400'. 
Response body: 
{
  "error": "invalid_request",
  "error_description": "
    AADSTS900023: Specified tenant identifier 'f837e147-205f-4bdf-9cfe-d07587a9ae3c' is neither a valid DNS name, nor a valid external domain.
    Trace ID: 75814be0-6217-44f9-896d-44a2063ffcd9
    Correlation ID: ee2dfe4b-f230-42e0-b571-f44387acfccb
    Timestamp: 2022-04-16 10:51:29Z
  "
}
Endpoint https://login.microsoftonline.com/e63649b2-07c0-49ed-a24b-87381dac292/oauth2/token?api-version=1.0 (order=https://acme-v02.api.letsencrypt.org/acme/order/499698030/80626411640) (ca=https://acme-v02.api.letsencrypt.org/directory)

Even though f837e147-205f-4bdf-9cfe-d07587a9ae3c was the correct ID for the tenant my Application & Service Principal were in. I found that I had to replace this with mycorporatedomain.com or mycorporatedomaincom.onmicrosoft.com (that is the DNS name of my tenant, unrelated to the DNS entry I am trying to get a certificate for) to get things to work.

tls {
    dns azure {
        tenant_id mycorporatedomain.com
        ...snip

Found in:

• [Azure Active Directory] > [Custom domain names]

[kurokobo]

@doug-fitzmaurice-rowden
Thanks for reporting.
I've tested it just now and could not reproduce it, using Caddy v2.4.6 with dns.providers.azure v0.2.0. My Caddyfile is here:

mydomain.example.com:443 {
    tls acme@example.com {
        ca https://acme-staging-v02.api.letsencrypt.org/directory
        dns azure {
            tenant_id "1e58****-****-****-****-********e9db"
            client_id "63cb****-****-****-****-********8a5e"
            client_secret "**********************************"
            subscription_id "96ff****-****-****-****-********7645"
            resource_group_name "dns"
        }
    }
    respond "Hello, world!"
}

Technicaly, this module (dns.providers.azure) just passes your tenant ID in the Caddyfile to the Azure Go SDK as is, and does not have any special handling around tenant ID, so I guess it is either your ID or your tenant issue. The ID can be found here:

The tenant_id shoud be an actual GUID of your tenant, but friendly DNS names which listed on Custom domain names page are also acceptable on the Azure API side. So if it's ok for you to use friendly name as tenant_id, you can keep using that.

[kurokobo]

Closing due to inactivity.
Please feel free to re-open this if you are still facing the issue.