Re: Action required: Let's Encrypt certificate renewals
Thanks. On 1/29/2019 11:19 PM, Dave Jones wrote: > On 1/29/19 1:35 PM, Kevin A. McGrail wrote: >> On 1/29/2019 2:25 PM, Dave Jones wrote: >>> On 1/29/19 10:20 AM, Bill Cole wrote: On 29 Jan 2019, at 10:25, Kevin A. McGrail wrote: >>> >>> So is this fixed on the sa-vm1.apache.org server or do I need to fix >>> it still? >>> >>> FYI, I found a better method for LE verification using the DNS-01 >>> method and a wrapper hook to ACME DNS: >>> >>> http://docs.cert-manager.io/en/master/reference/issuers/acme/dns01/acme-dns.html >>> >>> >>> >>> I setup the ACME DNS go server on auth.ena.net so I can host my own >>> _acme-challenge records via a CNAME. You can use the author's >>> auth.acme-dns.io server to get started. At home I set this up on my >>> pfSense firewall using the acme package. Now I have a wildcard cert >>> that I pull from my pfSense firewall to my raspi and push out to all >>> of my web servers so I have https everywhere and no annoying cert >>> warnings. >>> >>> ACME DNS allows for a server that is not reachable by the Internet to >>> be a central repository for all of your LE certs and automated >>> renewals. Then you push out the certs to all of your servers using >>> your favorite tool like Ansible, Puppet, Chef, Salt, shell script, etc. >>> >>> Dave >> >> This is NOT fixed. Bill and I were talking about it at work on a non-SA >> box and I thought it was interesting. >> > > I changed the challenge to use acme-dns and generated a wildcard cert > successfully which is live now. > > https://www.ssllabs.com/ssltest/analyze.html?d=ruleqa.spamassassin.org > > # cat /etc/letsencrypt/renewal/spamassassin.org.conf > [renewalparams] > pref_challs = dns-01, > manual_auth_hook = /etc/letsencrypt/acme-dns-auth.py > > > # head /etc/letsencrypt/acme-dns-auth.py > . > . > . > # URL to acme-dns instance > ACMEDNS_URL = "https://auth.acme-dns.io; > > > Dave -- Kevin A. McGrail VP Fundraising, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: Action required: Let's Encrypt certificate renewals
On 1/29/19 1:35 PM, Kevin A. McGrail wrote: On 1/29/2019 2:25 PM, Dave Jones wrote: On 1/29/19 10:20 AM, Bill Cole wrote: On 29 Jan 2019, at 10:25, Kevin A. McGrail wrote: So is this fixed on the sa-vm1.apache.org server or do I need to fix it still? FYI, I found a better method for LE verification using the DNS-01 method and a wrapper hook to ACME DNS: http://docs.cert-manager.io/en/master/reference/issuers/acme/dns01/acme-dns.html I setup the ACME DNS go server on auth.ena.net so I can host my own _acme-challenge records via a CNAME. You can use the author's auth.acme-dns.io server to get started. At home I set this up on my pfSense firewall using the acme package. Now I have a wildcard cert that I pull from my pfSense firewall to my raspi and push out to all of my web servers so I have https everywhere and no annoying cert warnings. ACME DNS allows for a server that is not reachable by the Internet to be a central repository for all of your LE certs and automated renewals. Then you push out the certs to all of your servers using your favorite tool like Ansible, Puppet, Chef, Salt, shell script, etc. Dave This is NOT fixed. Bill and I were talking about it at work on a non-SA box and I thought it was interesting. I changed the challenge to use acme-dns and generated a wildcard cert successfully which is live now. https://www.ssllabs.com/ssltest/analyze.html?d=ruleqa.spamassassin.org # cat /etc/letsencrypt/renewal/spamassassin.org.conf [renewalparams] pref_challs = dns-01, manual_auth_hook = /etc/letsencrypt/acme-dns-auth.py # head /etc/letsencrypt/acme-dns-auth.py . . . # URL to acme-dns instance ACMEDNS_URL = "https://auth.acme-dns.io; Dave
Re: Action required: Let's Encrypt certificate renewals
On 29 Jan 2019, at 14:25, Dave Jones wrote: So is this fixed on the sa-vm1.apache.org server or do I need to fix it still? I was relating work I did for a PCCC customer machine (which is why Kevin was aware of it) NOT sa-vm1. If you're familiar with how sa-vm1 was set up, it may be best that you fix it (or just confirm that it's got a new enough installation of whatever tool it is using to Just Work.) -- Bill Cole
Re: Action required: Let's Encrypt certificate renewals
On 1/29/19 10:20 AM, Bill Cole wrote: On 29 Jan 2019, at 10:25, Kevin A. McGrail wrote: FYI, I think this is your territory, Dave Bill had some interesting experience with the issue so cc'ing him. Only "interesting" because I didn't trust the simplicity of the fix. All I had to do on a fairly recent Certbot/CentOS7 installation was to update the Certbot package and related Python packages (all in EPEL) and verify that nothing in the config referenced tls-sni-01 explicitly. Running 'certbot renew --dry-run' ran happily. This was all in the LE/Certbot docs referenced in the warning message. What confused me was that the Apache server in question had a stack of vhosts, all of which had all port 80 requests redirected (via mod_rewrite) to their port 443 siblings, all of which required "Basic" authentication. The LE/Certbot information states that port 80 is required for http-01 verification, so I didn't see how it could work and did not see direct evidence of what certbot was doing. Upon closer investigation, I found that it temporarily wraps the vhost config with a mod_rewrite redirection of the challenge URL path, cleaning up after itself when done. A few directories got modified, but no remaining files were, so the only clear evidence of this was in the certbot debug log. In short: I expected a failure that I'd need to work around but that didn't happen. It just worked. So is this fixed on the sa-vm1.apache.org server or do I need to fix it still? FYI, I found a better method for LE verification using the DNS-01 method and a wrapper hook to ACME DNS: http://docs.cert-manager.io/en/master/reference/issuers/acme/dns01/acme-dns.html I setup the ACME DNS go server on auth.ena.net so I can host my own _acme-challenge records via a CNAME. You can use the author's auth.acme-dns.io server to get started. At home I set this up on my pfSense firewall using the acme package. Now I have a wildcard cert that I pull from my pfSense firewall to my raspi and push out to all of my web servers so I have https everywhere and no annoying cert warnings. ACME DNS allows for a server that is not reachable by the Internet to be a central repository for all of your LE certs and automated renewals. Then you push out the certs to all of your servers using your favorite tool like Ansible, Puppet, Chef, Salt, shell script, etc. Dave
Re: Action required: Let's Encrypt certificate renewals
On 29 Jan 2019, at 10:25, Kevin A. McGrail wrote: FYI, I think this is your territory, Dave Bill had some interesting experience with the issue so cc'ing him. Only "interesting" because I didn't trust the simplicity of the fix. All I had to do on a fairly recent Certbot/CentOS7 installation was to update the Certbot package and related Python packages (all in EPEL) and verify that nothing in the config referenced tls-sni-01 explicitly. Running 'certbot renew --dry-run' ran happily. This was all in the LE/Certbot docs referenced in the warning message. What confused me was that the Apache server in question had a stack of vhosts, all of which had all port 80 requests redirected (via mod_rewrite) to their port 443 siblings, all of which required "Basic" authentication. The LE/Certbot information states that port 80 is required for http-01 verification, so I didn't see how it could work and did not see direct evidence of what certbot was doing. Upon closer investigation, I found that it temporarily wraps the vhost config with a mod_rewrite redirection of the challenge URL path, cleaning up after itself when done. A few directories got modified, but no remaining files were, so the only clear evidence of this was in the certbot debug log. In short: I expected a failure that I'd need to work around but that didn't happen. It just worked. Forwarded Message ---- Subject: Action required: Let's Encrypt certificate renewals Date: Tue, 29 Jan 2019 02:14:39 + From: nore...@letsencrypt.org Reply-To: sysadmins@spamassassin.apache.org To: sysadmins@spamassassin.apache.org Hello, Action may be required to prevent your Let's Encrypt certificate renewals from breaking. If you already received a similar e-mail, this one contains updated information. Your Let's Encrypt client used ACME TLS-SNI-01 domain validation to issue a certificate in the past 60 days. Below is a list of names and IP addresses validated (max of one per account): ruleqa.spamassassin.org (62.210.60.231) on 2018-11-23 TLS-SNI-01 validation is reaching end-of-life. It will stop working temporarily on February 13th, 2019, and permanently on March 13th, 2019. Any certificates issued before then will continue to work for 90 days after their issuance date. You need to update your ACME client to use an alternative validation method (HTTP-01, DNS-01 or TLS-ALPN-01) before this date or your certificate renewals will break and existing certificates will start to expire. Our staging environment already has TLS-SNI-01 disabled, so if you'd like to test whether your system will work after February 13, you can run against staging: https://letsencrypt.org/docs/staging-environment/ If you're a Certbot user, you can find more information here: https://community.letsencrypt.org/t/how-to-stop-using-tls-sni-01-with-certbot/83210 Our forum has many threads on this topic. Please search to see if your question has been answered, then open a new thread if it has not: https://community.letsencrypt.org/ For more information about the TLS-SNI-01 end-of-life please see our API announcement: https://community.letsencrypt.org/t/february-13-2019-end-of-life-for-all-tls-sni-01-validation-support/74209 Thank you, Let's Encrypt Staff -- Bill Cole
Fwd: Action required: Let's Encrypt certificate renewals
FYI, I think this is your territory, Dave Bill had some interesting experience with the issue so cc'ing him. Forwarded Message Subject:Action required: Let's Encrypt certificate renewals Date: Tue, 29 Jan 2019 02:14:39 + From: nore...@letsencrypt.org Reply-To: sysadmins@spamassassin.apache.org To: sysadmins@spamassassin.apache.org Hello, Action may be required to prevent your Let's Encrypt certificate renewals from breaking. If you already received a similar e-mail, this one contains updated information. Your Let's Encrypt client used ACME TLS-SNI-01 domain validation to issue a certificate in the past 60 days. Below is a list of names and IP addresses validated (max of one per account): ruleqa.spamassassin.org (62.210.60.231) on 2018-11-23 TLS-SNI-01 validation is reaching end-of-life. It will stop working temporarily on February 13th, 2019, and permanently on March 13th, 2019. Any certificates issued before then will continue to work for 90 days after their issuance date. You need to update your ACME client to use an alternative validation method (HTTP-01, DNS-01 or TLS-ALPN-01) before this date or your certificate renewals will break and existing certificates will start to expire. Our staging environment already has TLS-SNI-01 disabled, so if you'd like to test whether your system will work after February 13, you can run against staging: https://letsencrypt.org/docs/staging-environment/ If you're a Certbot user, you can find more information here: https://community.letsencrypt.org/t/how-to-stop-using-tls-sni-01-with-certbot/83210 Our forum has many threads on this topic. Please search to see if your question has been answered, then open a new thread if it has not: https://community.letsencrypt.org/ For more information about the TLS-SNI-01 end-of-life please see our API announcement: https://community.letsencrypt.org/t/february-13-2019-end-of-life-for-all-tls-sni-01-validation-support/74209 Thank you, Let's Encrypt Staff
Action required: Let's Encrypt certificate renewals
Hello, Action may be required to prevent your Let's Encrypt certificate renewals from breaking. If you already received a similar e-mail, this one contains updated information. Your Let's Encrypt client used ACME TLS-SNI-01 domain validation to issue a certificate in the past 60 days. Below is a list of names and IP addresses validated (max of one per account): ruleqa.spamassassin.org (62.210.60.231) on 2018-11-23 TLS-SNI-01 validation is reaching end-of-life. It will stop working temporarily on February 13th, 2019, and permanently on March 13th, 2019. Any certificates issued before then will continue to work for 90 days after their issuance date. You need to update your ACME client to use an alternative validation method (HTTP-01, DNS-01 or TLS-ALPN-01) before this date or your certificate renewals will break and existing certificates will start to expire. Our staging environment already has TLS-SNI-01 disabled, so if you'd like to test whether your system will work after February 13, you can run against staging: https://letsencrypt.org/docs/staging-environment/ If you're a Certbot user, you can find more information here: https://community.letsencrypt.org/t/how-to-stop-using-tls-sni-01-with-certbot/83210 Our forum has many threads on this topic. Please search to see if your question has been answered, then open a new thread if it has not: https://community.letsencrypt.org/ For more information about the TLS-SNI-01 end-of-life please see our API announcement: https://community.letsencrypt.org/t/february-13-2019-end-of-life-for-all-tls-sni-01-validation-support/74209 Thank you, Let's Encrypt Staff
