Issues with Let's Encrypt host certs

[jlixfeld]

I've got Let's Encrypt certificates set up for hostname.mydomain.com as well as www.mydomain.com and mail.mydomain.com:

# more /usr/local/directadmin/conf/ca.san_config
[ req_distinguished_name ]
CN = hosting1.tor1.mydomain.com
[ req ]
distinguished_name = req_distinguished_name
[SAN]
subjectAltName=DNS:hosting1.tor1.mydomain.com

# more /usr/local/directadmin/data/users/admin/domains/mydomain.com.san_config
[ req ]
default_bits		= 4096
default_keyfile		= keyfile.pem
distinguished_name	= req_distinguished_name
attributes		= req_attributes
prompt			= no
output_password		= bogus

[ req_distinguished_name ]
C			= CA
ST			= Ontario
L			= Toronto
O			= My Domain
CN			= mydomain.com
emailAddress	= [email protected]

[ req_attributes ]
[ SAN ]
subjectAltName=DNS:mydomain.com, DNS:www.mydomain.com, DNS:mail.mydomain.com

If I browse to https://mydomain.com, the page is secured. If I browse to https://www.mydomain.com or https://mail.mydomain.com, I get a certificate warning saying the cert for those hosts are invalid. I've attached a screen shot of the warning.



I've tried to revoke the certificate and re-request it, renew it, re-request it, but no matter what I try it's still invalid.

# ./letsencrypt.sh revoke mydomain.com 4096
Certificate has been successfully revoked.
# ./letsencrypt.sh reqeust mydomain.com 4096
Getting challenge for mydomain.com from acme-server...
Waiting for domain verification...
Challenge is valid.
Getting challenge for www.mydomain.com from acme-server...
Waiting for domain verification...
Challenge is valid.
Getting challenge for mail.mydomain.com from acme-server...
Waiting for domain verification...
Challenge is valid.
Generating 4096 bit RSA key for mydomain.com...
openssl genrsa 4096 > "/usr/local/directadmin/data/users/admin/domains/mydomain.com.key.new"
Generating RSA private key, 4096 bit long modulus
...............................++
.++
e is 65537 (0x10001)
Certificate for mydomain.com has been created successfully!
#

One thing I did notice is that in the certificate warning, the date in the certificate details is the same even after I revoke or renew it or request it, so it seems clear that through whatever process, the new certificate is not being copied to nginx or dovecom/exim. I tried to manually delete those certificates and re-requested the certs, but that doesn't copy the certs back to nginx or dovecot/exim.

Is my hunch correct? Is the issue that the old certificate isn't properly getting overwritten with the new one after requesting the new certificate after adding the new DNS: entries?

Any ideas on how I can force that to happen?

Thanks!

 

[jlixfeld]

*bump & update*

I've tried to re-create the LE certs after upgrading to 1.50.1, but I'm still getting the same cert warning that I got in my post above in the included attachment.

I shouldn't be getting that error, right? If the proper entry is in the san_config for that domain, there shouldn't be any errors thrown by my browser/mail client, correct?

Since the 1.50.1 upgrade, here are the relevant (I think) bits:

root@hosting1:/usr/local/directadmin/scripts# more /usr/local/directadmin/conf/ca.san_config
[ req_distinguished_name ]
CN = hosting1.tor1.ariohosts.ca
[ req ]
distinguished_name = req_distinguished_name
[SAN]
subjectAltName=DNS:hosting1.tor1.ariohosts.ca
root@hosting1:/usr/local/directadmin/scripts# more /usr/local/directadmin/data/users/admin/domains/ariohosts.ca.san_config
[ req ]
default_bits		= 4096
default_keyfile		= keyfile.pem
distinguished_name	= req_distinguished_name
attributes		= req_attributes
prompt			= no
output_password		= bogus

[ req_distinguished_name ]
CN			= ariohosts.ca
emailAddress		= [email]hostmaster-at-ariohosts.ca[/email]

[ req_attributes ]
[ SAN ]
subjectAltName=DNS:ariohosts.ca, DNS:mail.andromedas.com, DNS:mail.ariohosts.ca, DNS:mail.arionetworks.ca, DNS:mail.lixfeld.ca, DNS:mail.self-mastery.ca, DNS:mail.selfmastery.ca
root@hosting1:/usr/local/directadmin/scripts#

 

[zEitEr]

Hello,

By default neither nginx nor Apache have mail.* in a list of server aliases or server names, so it points to a default virtual host with hostname in it with hostname's cert. So you should either add mail.* as an alias (or separate virtualhost) to your existing domains, or add certs for mail.* into server default SSL/TLS cert.

- Setting up webmail.domain.com as default for new domains.
http://help.directadmin.com/item.php?id=92

 

[jlixfeld]

Hi Alex,

Thanks for the tip! I tend to get the same errors with a standard mail client i.e.: Apple Mail which has nothing to do with browsers, and I'm not sure how to correct them. With the same configuration as in my second post, my client sends me certificate errors saying the cert is invalid.. pretending to be... blah blah. This is despite the correct entry for the mail server in the LE configuration SAN entry:



Any thoughts there? Admittedly, this is very much over my head.

Thanks!

 

[zEitEr]

I see the cert has only hostname without mail.*. Did you request to reissue cert after you changed SAN entry? For the hostname correct SAN config can be found in /usr/local/directadmin/conf/

 

[jlixfeld]

Indeed:

# /usr/local/directadmin/conf/ca.san_config 
[ req_distinguished_name ]
CN = hosting1.tor1.ariohosts.ca
[ req ]
distinguished_name = req_distinguished_name
[SAN]
subjectAltName=DNS:hosting1.tor1.ariohosts.ca

So you are saying that I need the SAN DNS: entries there, not in /usr/local/directadmin/data/users/admin/domains/ariohosts.ca.san_config as they are now:

#/usr/local/directadmin/data/users/admin/domains/ariohosts.ca.san_config 
[ req ]
default_bits		= 4096
default_keyfile		= keyfile.pem
distinguished_name	= req_distinguished_name
attributes		= req_attributes
prompt			= no
output_password		= bogus

[ req_distinguished_name ]
CN			= ariohosts.ca
emailAddress		= [email protected]

[ req_attributes ]
[ SAN ]
subjectAltName=DNS:ariohosts.ca, DNS:mail.andromedas.com, DNS:mail.ariohosts.ca, DNS:mail.arionetworks.ca, DNS:mail.lixfeld.ca, DNS:mail.self-mastery.ca, DNS:mail.selfmastery.ca

I'm not sure what you are referring to by request to re-issue. I created this cert using the User Level > <domain> > SSL Certificate GUI and checked all the boxes for the mail.* entires I wanted.

Take it that is not the correct method to do what it is I'm trying to do?

Thanks again in advance!

 

[zEitEr]

Yes, you should update /usr/local/directadmin/conf/ca.san_config with your mail.* domains if you want to use them when connecting to a mail server over SSL/TLS encrypted connection.

By re-issue I mean the fact that you need to renew the cert after you change a list of domains, ie Let'S Encrypt should be asked to provide a new cert. Usually you can do it with letsencrypt script in root console.

 

[jlixfeld]

Interesting. That worked perfectly, but I really don't understand how or why I had to do that on the CLI. Shouldn't the DA > User Level > <domain> > SSL Certificates area be able to do this, or is that GUI only for creating https certs; if someone wanted certs for the smtp/imap/pop, they'd need to have someone with root access do this?

 

[zEitEr]

Directadmin by default does not add users certs into exim/dovecot/proftpd. That's how it was designed and how it works now. Consider opening a ticket with a feature request if you want other behavior. But you should take into consideration limits which it brings to you when using certs from Let's Encrypt.

Let’s Encrypt has the following rate limits in place:

• Names/Certificate is the limit on how many domain names you can include in a single certificate. This is currently limited to 100 names, or websites, per certificate issued.
• Certificates/Domain you could run into through repeated re-issuance. This limit measures certificates issued for a given combination of Public Suffix + Domain (a "registered domain"). This is limited to 5 certificates per domain per week.
• Registrations/IP address limits the number of registrations you can make in a given time period; currently 500 per 3 hours. This limit should only affect the largest users of Let's Encrypt.
• Pending Authorizations/Account limits how many times an ACME client can request a domain name be authorized without actually fulfilling on the request itself. This limit is set to 300 per account per week.

There is no limit to the number of certificates that can be issued to different domains.

You will most likely run out of limits with Let's Encrypt if you add every new domain into server's main cert. So it will hardly be an official part of Directadmin (that's my thoughts only though) in the near future. Alternatively for end-users you might consider using SNI with dovecot and exim, but some web-clients do not support SNI. And in this case it will require from you that you customize exim/dovecot configs and use directadmin hook scripts. We have experience with a customization of such a kind, and have ready solutions. So if you want to get it from us, you might consider hiring us for this.

 

[jlixfeld]

Ah. With the LE imposed limits, it makes perfect sense why DA doesn't do this by default. Perhaps down the road when LE doesn't have these rate limits (if ever)...

Right now, adding to my server's main cert is fine for my needs.

Thanks again for all your help. I'm grateful!