Let's Encrypt and Azure Private DNS

[ceilingfish]

Hello,
I'm trying to generate a wildcard Let's Encrypt certificate for an Azure Private DNS zone. This is so some internal sites can have a valid SSL certificate, but cannot be accessed from the public internet.

The domain I was trying to issue a certificate for was *.internal.not-the-real-domain.com, where internal.not-the-real-domain.com is my azure private DNS zone.

I ran this command:

certbot certonly --manual --manual-auth-hook .\Invoke-AuthHook.ps1 --manual-cleanup-hook .\Invoke-AuthCleanup.ps1 --noninteractive --agree-tos --email my-email@example.com -d *.internal.not-the-real-domain.com

The Invoke-AuthHook.ps1 script looks like:

Import-Module Az.PrivateDns

New-AzPrivateDnsRecordSet `
        -ZoneName 'internal.not-the-real-domain.com' `
        -ResourceGroupName 'a-resource-group' `
        -RecordType TXT `
        -Ttl 300 `
        -Name '_acme-challenge' `
        -Overwrite `
        -PrivateDnsRecord @(New-AzPrivateDnsRecordConfig -Value $env:CERTBOT_VALIDATION)

The Invoke-AuthCleaup.ps1 script looks like:

Import-Module Az.PrivateDns

Remove-AzPrivateDnsRecordSet `
         -ZoneName 'internal.not-the-real-domain.com' `
        -ResourceGroupName 'a-resource-group' `
        -RecordType TXT `
        -Name '_acme-challenge'

It produced this output:

Certbot failed to authenticate some domains (authenticator: manual). The Certificate Authority reported these problems:
  Domain: internal.not-the-real-domain.com
  Type:   dns
  Detail: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.internal.not-the-real-domain.com - check that a DNS record exists for this domain

Analysing the traffic with Wireshark, I can see that there isn't actually a DNS lookup made from certbot for that record. Does this mean it's actually done from a different server in a Let's Encrypt data center somewhere? If so, is there any guidance on using Let's Encrypt for this kind of scenario, or do I have to use a self-signed certificate instead?

The version of my client is 1.22.0

[Osiris]

@ceilingfish

Does this mean it's actually done from a different server in a Let's Encrypt data center somewhere?

Correct, Certbot does not verify anything, it's just the ACME client whereas the ACME server does all the validating.

Please see:

How It Works - Let's Encrypt

@ceilingfish

If so, is there any guidance on using Let's Encrypt for this kind of scenario

Let's Encrypt is a publicly trusted CA and therefore requires a publicly accessible domain name, either through DNS, HTTP on port 80 or using the ALPN challenge on port 443. Let's Encrypt can not and never will issue certificates for local only domain names.

@ceilingfish

or do I have to use a self-signed certificate instead?

For non-public domains you can only use self-signed certificates or set up your own (internal) CA.

[ceilingfish]

Hi Osiris,
That's provided useful clarity. Many thanks

[schoen]

Just to add to @Osiris's explanation:

Note that if you do publicly register a domain, you can get certificates for it without having any A records with public IP addresses (using the DNS challenge method). The domain has to exist with a DNS registrar and be present in public DNS, but you don't have to have any publicly-accessible servers or services in order to get a certificate.

You could, that is, use private DNS for your servers (A / AAAA records) and public DNS for your certificate validation proof (TXT records, which can be temporary).

If you do this, your certificates will also be visible in Certificate Transparency, so there will also be a public record of the fact that the names on the certificates exist. (Those records are permanent.) But that doesn't necessarily mean that anyone will also be able to connect to them from the public Internet.

So, depending on the level of secrecy and unofficialness that you're looking for, Let's Encrypt (and a publicly trusted certificate) might or might not be relevant to you.