Wildcard Certificates on Alpine


#1

Problem description:

I’m trying to get wildcard certificates to work for my rescopa.com domain. I’m using a docker-compose project from Mailu. It instantiates an Apline based nginx container for the front end which has certbot running hourly to generate certificates.

When I try to access the smtp.rescopa.com domain (to send some mail, fwiw), the certificate returned is for rescopa.com. Not *.rescopa.com. As a result, Thunderbird refuses to complete the SMTP request.

From reading the docs, it looks like the command below should issue wildcard certificates. Is there some other configuration I need to do? There is a mention of some kind of DNS hook, but certbot is run standalone, so I’m not sure what might need hooking.

Thanks for any help or doc links.

-Mark

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: rescopa.com,mail.rescopa.com,smpt.rescopa.com,thefamilycore.com,mail.thefamilycore.com,smtp.thefamilycore.com

I ran this command: certbot -n --agree-tos -d “.rescopa.com,.thefamilycore.com” -m postmaster@rescopa.com certonly --standalone --cert-name mailu --preferred-challenges http --http-01-port 8008 --keep-until-expiring --rsa-key-size 4096 --config-dir /certs/letsencrypt --post-hook /config.py

It produced this output: Pastebin to bad certificate: https://pastebin.com/6nQByyCi

My web server is (include version): nginx v1.12.2

The operating system my web server runs on is (include version): Alpine linux v3.7.0

My hosting provider, if applicable, is: Not really applicable, but I’m running a VPS hosted by IOZoom.com out of L.A.

I can login to a root shell on my machine (yes or no, or I don’t know): yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): No


#2

I’m not sure if the forum screwed up your formatting, but the correct syntax for a wildcard is:

-d "*.rescopa.com" -d "*.thefamilycore.com"

If you’re not aware, it is not possible to get a wildcard certificate using HTTP validation. You must use DNS validation.

This means that --standalone, --apache, --nginx etc are all out of the question.

For that reason, it is desirable to avoid wildcards if at all possible.

Your options for DNS validation will depend on who your DNS host for your domains is.


#3

@_az Side note: if the command line was really -d ".rescopa.com" shouldn’t certbot raise an error?


#4

You are right - it does raise an error. It’s not clear to me how the listed command could have succeeded either way.


#5

The command fails. That is why I posted the help request. :wink:

As I mentioned, this is part of a docker-compose configuration for Mailu. My question is “What should the command look like to successfully generate wildcard certificates?”

FWIW, in order to keep things working I had to back out the wildcard change. The -d option that is currently running is: -d "rescopa.com,www.rescopa.com,mail.rescopa.com,smtp.rescopa.com,thefamilycore.com,www.thefamilycore.com,mail.thefamilycore.com,smtp.thefamilycore.com"

But, that only covers the most basic subdomains and is already approaching the 10 limit on hourly certs. That’s why I’m really hoping to be able to get wildcard certs working. B-)


#6

@_az, the markdown magic did strip the asterisks. :frowning: The actual -d option I tried to get wildcarding to work with was: -d "*.rescopa.com,*.thefamilycore.com"


#7

@_az, I did not realize certbot’s wildcarding required a custom DNS server. I currently use GoDaddy.com to manage the DNS. But, I control the domain, so I can move the nameserver pointers if that’s what’s required.

Is there a recommended DNS solution for certbot wildcarding? If it fits in an Alpine docker container, that would be especially awesome.


#8

Just to clarify, the limit is on certificates, not domains in the certificates: you can have up to 100 domains in a single certificate.

(When experimenting, to avoid reach rates limits, you should use the staging environment)

Furthermore, when using a wildcard certificate, if you have multiple servers, you should be careful about the configuration of your web servers to avoid virtual host confusion attacks.


#9

@tdelmas, thanks for the heads up. The docker-compose group has a single outward facing container called front. It is the nginx server (router) that fields and proxies the requests to a cluster of docker networked containers. The relevant containers are the imap server and the postman based smtp server.

I’m guessing the Mailu configuration is robust against virtual host confusion attacks, but I’ll posta question on their forum to see if anyone knows about that potential issue.


#10

@tdelmas, your response seems to imply that the certificate I get from certbot should support multiple domain names. But, the certificate my email client (Thunderbird v52.8.0) actually receives only lists CN=rescopa.com. IS there a different option/setting I need to pass into certbot to request a certificate that supports multiple domians?


#11

On which domain/port do you have the problem with Thunderbird?


#12

All of the names are listed in the subject alternative name extension.

https://crt.sh/?id=478198583

Scroll down to “subject alternative name”.

The CN can only refer to one name and is an obsolescent method for referring to the subject of the certificate. Let’s Encrypt has been considering removing it entirely. No CA would issue you a certificate with multiple names in the CN field. :slight_smile:

If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead.

https://tools.ietf.org/html/rfc2818 (now 18 years old!)


#13

After looking in crt.sh, you’ve only issued two certificates this week and so you aren’t very close to the Certificates per Registered Domain or Duplicate Certificate rate limits. These are weekly rate limits; I’m not sure which hourly limit you were referring to. If you do know all of the hostnames ahead of time, @tdelmas’s suggestion to list them all explicitly and avoid the use of a wildcard should be totally practical!


#14

The (effective) requirement is that the DNS host have an API that’s supported by the ACME client you’re using. I say (effective) requirement because it’s entirely possible to validate manually, but then you’d need to do that every few months–to automate issuance and renewal, the API needs to be there.

There are several DNS hosts that will work; Cloudflare is free for DNS hosting and has a pretty well-supported API. Another option is to host your own acme-dns instance for validation purposes.


#15

Thank you all for the responses. I still don’t have the problem solved, but it feels like it’s getting chased into a corner.

@tdelmas, the domain/port that is returning the bad certificate is smtp.rescopa.com:587

@schoen, I can see that subject alternative name extension on https://crt.sh/?id=478198583 And, thank for the clarification on CN. I’m definitely not an expert in certificate fields, so I had no idea that was obsolete and only supported a single domain name.

Unfortunately, the actual certificate that is returned does not include the subject alternative name section, so it does not support the other domains. Here is a copy of the certificate that Thunderbird receives from smtp.rescopa.com:587: https://pastebin.com/Rb48Xhjq

I suspect there is either a certificate cache I need to clear in the Mailu docker-compose containers, or that there is a configuration error between the nginx frontend router and the postman smtp server.


#16

The certificate in the Pastebin includes:

        Subject: CN=rescopa.com

            X509v3 Subject Alternative Name: 
                DNS:mail.rescopa.com, DNS:rescopa.com

Edit: It’s this certificate:

https://crt.sh/?id=449615547


#17

@mnordhoff, you are correct. But, it still doesn’t contain smtp.rescopa.com, so it fails. :frowning:

As I mentioned in the previous response, it looks like there is some cache issue.

I’ve been able to confirm that on the mailu_front_1 container, the softlinks in /certs/letsencrypt/live/mailu/*.pem point to the correct files in ../../archive/mailu/. For example, fullchain.pem --> ../../archive/mailu/fullchain2.pem. The fullchain2.pem[1] includes smtp.rescopa.com.

What is strange is that the certificate served up to smtp.rescopa.com:587 is not the fullchain.pem, and it’s not any of the other certs in the /certs/letsencrypt/live/mailu/ directory. It’s ../../archive/mailu/cert1.pem

Why would certbot/nginx pick cert.pem over fullchain.pem? And, how could it even find ../../archive/mailu/cert1.pem??

This seems to be something the nginx frontend is doing, so I’m hoping someone here might recognize the issue.

[1] fullchain2.pem: https://pastebin.com/uNWdzmnY


#18

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.