[SOLVED] CAA failure renewing wildcard certificates

[Maeyanie]

My domain is:
deathwyrm.com
deathwyrm.net
maeyanie.com

I ran this command:
/bin/certbot renew
–server https://acme-v02.api.letsencrypt.org/directory
–post-hook “/opt/letsencrypt/renew-post.sh”

It produced this output:
Attempting to renew cert (deathwyrm.net) from /etc/letsencrypt/renewal/deathwyrm.net.conf produced an unexpected error: Failed autho
rization procedure. deathwyrm.com (dns-01): urn:ietf:params:acme:error:caa :: CAA record for *.deathwyrm.com prevents issuance, maey
anie.com (dns-01): urn:ietf:params:acme:error:caa :: CAA record for *.maeyanie.com prevents issuance, deathwyrm.net (dns-01): urn:ie
tf:params:acme:error:caa :: CAA record for *.deathwyrm.net prevents issuance. Skipping.

My web server is (include version):
nginx/1.12.2

The operating system my web server runs on is (include version):
CentOS 7

My hosting provider, if applicable, is:
N/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

Other important information:
My DNS provider (Cloudflare) does support CAA records, and I have them set up to allow “letsencrypt.org” as instructed in https://letsencrypt.org/docs/caa/
It worked for issuing this certificate however many days ago, but now that CertBot is trying to auto-renew, it doesn’t like it.

[sahsanu]

Hi @Maeyanie,

You don’t allow letsencrypt to issue wildcard certificates…

deathwyrm.net.          300     IN      CAA     0 issuewild "comodoca.com"
deathwyrm.net.          300     IN      CAA     0 issuewild "digicert.com"
deathwyrm.net.          300     IN      CAA     0 issuewild "globalsign.com"
deathwyrm.net.          300     IN      CAA     0 issue "letsencrypt.org"
deathwyrm.net.          300     IN      CAA     0 issue "comodoca.com"
deathwyrm.net.          300     IN      CAA     0 issue "digicert.com"
deathwyrm.net.          300     IN      CAA     0 issue "globalsign.com" 

maeyanie.com.           300     IN      CAA     0 issuewild "globalsign.com"
maeyanie.com.           300     IN      CAA     0 iodef "mailto:me@maeyanie.com"
maeyanie.com.           300     IN      CAA     0 issue "letsencrypt.org"
maeyanie.com.           300     IN      CAA     0 issue "comodoca.com"
maeyanie.com.           300     IN      CAA     0 issue "digicert.com"
maeyanie.com.           300     IN      CAA     0 issue "globalsign.com"
maeyanie.com.           300     IN      CAA     0 issuewild "comodoca.com"
maeyanie.com.           300     IN      CAA     0 issuewild "digicert.com"

deathwyrm.com.          300     IN      CAA     0 issuewild "comodoca.com"
deathwyrm.com.          300     IN      CAA     0 issuewild "digicert.com"
deathwyrm.com.          300     IN      CAA     0 issuewild "globalsign.com"
deathwyrm.com.          300     IN      CAA     0 issue "letsencrypt.org"
deathwyrm.com.          300     IN      CAA     0 issue "comodoca.com"
deathwyrm.com.          300     IN      CAA     0 issue "digicert.com"
deathwyrm.com.          300     IN      CAA     0 issue "globalsign.com"

…you only allow, GlobalSign, Comodo and DigiCert. Maybe when you issued the wildcard cert you didn’t have issuewild CAA records but once you have added them, LE can’t see its name there so it is not allowed to issue a wildcard cert for your domains. Just add an issuewild "letsencrypt.org" to solve the problem.

Cheers,
sahsanu

[rg305]

You might want to use HSTS - that should get you an A+ on SSL Labs.
Also, look into reordering your supported curves:
http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_ecdh_curve

[_az]

To add, if you want to avoid that ginormous list of CAs, you can disable Universal SSL in your Cloudflare crypto settings, and Cloudflare will stop sending those CAA records.

(As long as you don’t use Universal SSL, of course).

[Maeyanie]

@sahsanu:
Yep, that worked, thanks. I made the mistake of assuming because it worked before, it should be right now, but things can change over a couple of months.

@rg305:
I do use HSTS, though with a shorter-than-recommended time while I’m making sure it doesn’t break anything. Is there a recommended curve order anywhere?

Edit: Seems there’s not a whole lot of curves in the version of OpenSSL included in CentOS, so just ranked them by descending bit-length. Thanks again to everyone.

[rg305]

@Maeyanie

Is there a recommended curve order anywhere?

For nginx, I use:
ssl_ecdh_curve sect571r1:secp521r1:brainpoolP512r1:sect409r1:brainpoolP384r1:secp384r1;

And for those who may be reading this and use Apache, I use:
SSLOpenSSLConfCmd Curves sect571r1:sect571k1:secp521r1:sect409r1:sect409k1:secp384r1:brainpoolP512r1:brainpoolP384r1:sect283r1:sect283k1

[mnordhoff]

Nginx and OpenSSL’s default curve settings are usually fine.

OpenSSL 1.1.0 uses X25519, P-256, P-521 and P-384.

Most versions of 1.0.2 use a longer list including some obscure curves, which is fine-ish.

The two releases 1.0.2 and 1.0.2a are bad.

Old releases just use P-256.