1 48dbae49 2023-03-19 jrmu version=pmwiki-2.3.20 ordered=1 urlencoded=1
2 48dbae49 2023-03-19 jrmu agent=Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/111.0
4 5127fd58 2021-12-17 jrmu charset=UTF-8
5 48dbae49 2023-03-19 jrmu csum=add command for counting certs
6 5127fd58 2021-12-17 jrmu ctime=1633095023
7 c17be54b 2022-09-06 jrmu host=2600:4040:2c6f:2200::212
8 5127fd58 2021-12-17 jrmu name=Letsencrypt.Expired
11 48dbae49 2023-03-19 jrmu text=On Sep 30, 2021, Let's Encrypt had [[https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire|one of their intermediate certificates expire]] (an old DST Root CA X3 certificate).%0aThis certificate is still present in the public certificates that they issue%0ato attempt maintaining compatibility with old android devices.%0aNormally, this would not be a problem, because Let's Encrypt offers%0aanother valid signature. However, broken SSL implementations %0awill reject the certificate. This includes OpenBSD 6.9 release and older,%0aand older versions of mIRC.%0a%0aSwitching to another certificate authority would normally help. However, mIRC%0ausers have complained about validation errors. It seems they are missing one%0aof the certificate authorities used by buypass. For this reason, do%0a'''not''' use buypass for your TLS certificates.%0a%0aLet's Encrypt allows you to request a certificate without this expired chain,%0ausing @@--preferred-chain 'ISRG Root X1'@@ on certbot for example,%0ahowever openbsd's acme-client does not support this.%0a%0aThe best solution is to use Let's Encrypt issued certificates%0awhile also deleting the extra intermediate certificate that has expired.%0a%0aGo to @@/etc/ssl/@@ where your public certificates are stored and edit%0a@@/etc/ssl/example.com.fullchain.pem@@. Delete the lines of the third%0a(and last) certificate by running this command '''as root''':%0a%0a[@%0a# awk '/END CERTIFICATE/ { cert++; } { print $0; if (cert == 2) exit;}' /etc/ssl/example.com.fullchain.pem > /etc/ssl/example.com.fullchain.pem.fixed%0a# mv /etc/ssl/example.com.fullchain.pem.fixed /etc/ssl/example.com.fullchain.pem%0a@]%0a%0aYou should repeat this for every single SSL cert you have. Then,%0aif the daemon that serves the cert is running inside a chroot, make sure%0ato copy the SSL cert into the chroot. For example, for ngircd:%0a%0a[@%0a$ doas cp /etc/ssl/example.com.fullchain.pem /etc/ssl/private/example.com.key /etc/ngircd/%0a$ doas chown _ngircd:_ngircd /etc/ngircd/example.com.{fullchain.pem,key}%0a$ doas pkill -HUP ngircd%0a@]%0a%0aWe make sure to set the proper permissions as well as send a HUP%0asignal to ngircd to cause it to reload its cert.%0a%0aFor ZNC, we would run:%0a%0a[@%0a$ doas cp /etc/ssl/example.com.fullchain.pem /etc/ssl/private/example.com.key /home/znc/home/znc/.znc/%0a$ doas chown -R znc:znc /home/znc/home/znc/.znc/%0a@]%0a%0aMake sure that certs are properly copied into place for all your services.%0a%0aTest to see if every one of your SSL certs work. It's best to use%0aa wide variety of web browsers, email clients, and IRC clients on preferably%0adifferent operating systems. For example, an SSL cert might validate%0aon Firefox on Debian but not on lynx on OpenBSD or mIRC on Windows.%0a%0a!! Recommended Testing:%0a%0aTry testing with mIRC from Windows if you have it, or irssi on unpatched%0aOpenBSD 6.9 release to your IRC server/ZNC bouncer. Also, try lynx/w3m on%0aOpenBSD to your website, and mutt on OpenBSD to your mail server. Try to%0asee if you can trigger the error before deleting the certificate, and if%0ayou have a valid certificate after it's deleted.%0a%0aFor a primitive method of checking (which specifically only applies to%0aLetsEncrypt certs), you can also try simply counting the number of certs%0athat get offered:%0a%0a[@%0a$ openssl s_client -showcerts -connect example.com:443 %3c/dev/null 2>/dev/null | grep '\-----END CERTIFICATE-----' | wc -l%0a@]%0a%0a* @@1@@ means your trust chain is missing, making it unverifiable by most devices%0a* @@2@@ is correct%0a* @@3@@ means you still have the expired cert in your trust chain%0a%0a!! Patching OpenBSD%0a%0aIn [[https://www.openbsd.org/errata69.html|Errata for OpenBSD 6.9]], a patch%0ais provided so that OpenBSD will verify trusted certificates first:%0a%0a[@%0a$ doas syspatch%0a@]%0a%0aSee also [[http://undeadly.org/cgi?action=article;sid=20211001073034]]%0a
12 48dbae49 2023-03-19 jrmu time=1679197601
13 48dbae49 2023-03-19 jrmu author:1679197601=xfnw
14 48dbae49 2023-03-19 jrmu csum:1679197601=add command for counting certs
15 48dbae49 2023-03-19 jrmu diff:1679197601:1662422401:=64,75d63%0a%3c %0a%3c For a primitive method of checking (which specifically only applies to%0a%3c LetsEncrypt certs), you can also try simply counting the number of certs%0a%3c that get offered:%0a%3c %0a%3c [@%0a%3c $ openssl s_client -showcerts -connect example.com:443 %3c/dev/null 2>/dev/null | grep '\-----END CERTIFICATE-----' | wc -l%0a%3c @]%0a%3c %0a%3c * @@1@@ means your trust chain is missing, making it unverifiable by most devices%0a%3c * @@2@@ is correct%0a%3c * @@3@@ means you still have the expired cert in your trust chain%0a
16 48dbae49 2023-03-19 jrmu host:1679197601=2600:4040:2c6f:2200::212
17 c17be54b 2022-09-06 jrmu author:1662422401=xfnw
18 c17be54b 2022-09-06 jrmu csum:1662422401=be less misleading about Let's Encrypt's reasoning for keeping the expired chain
19 c17be54b 2022-09-06 jrmu diff:1662422401:1633445210:=2,3c2%0a%3c This certificate is still present in the public certificates that they issue%0a%3c to attempt maintaining compatibility with old android devices.%0a---%0a> This certificate is still present in the public certificates that they issue.%0a5,6c4,5%0a%3c another valid signature. However, broken SSL implementations %0a%3c will reject the certificate. This includes OpenBSD 6.9 release and older,%0a---%0a> another valid signature. However, older SSL implementations %0a> will reject the certificate. This includes OpenBSD 6.9 release and older%0a13,16d11%0a%3c %0a%3c Let's Encrypt allows you to request a certificate without this expired chain,%0a%3c using @@--preferred-chain 'ISRG Root X1'@@ on certbot for example,%0a%3c however openbsd's acme-client does not support this.%0a
20 c17be54b 2022-09-06 jrmu host:1662422401=2600:4040:2c6f:2200::212
21 5127fd58 2021-12-17 jrmu author:1633445210=miniontoby
22 c17be54b 2022-09-06 jrmu csum:1633445210=added .pem
23 5127fd58 2021-12-17 jrmu diff:1633445210:1633284282:=22c22%0a%3c # mv /etc/ssl/example.com.fullchain.pem.fixed /etc/ssl/example.com.fullchain.pem%0a---%0a> # mv /etc/ssl/example.com.fullchain.fixed /etc/ssl/example.com.fullchain.pem%0a
24 5127fd58 2021-12-17 jrmu host:1633445210=77.168.188.164
25 5127fd58 2021-12-17 jrmu author:1633284282=jrmu
26 5127fd58 2021-12-17 jrmu diff:1633284282:1633106360:=68,69d67%0a%3c %0a%3c See also [[http://undeadly.org/cgi?action=article;sid=20211001073034]]%0a
27 5127fd58 2021-12-17 jrmu host:1633284282=125.231.16.47
28 5127fd58 2021-12-17 jrmu author:1633106360=jrmu
29 5127fd58 2021-12-17 jrmu diff:1633106360:1633105248:=51,60d50%0a%3c %0a%3c !! Recommended Testing:%0a%3c %0a%3c Try testing with mIRC from Windows if you have it, or irssi on unpatched%0a%3c OpenBSD 6.9 release to your IRC server/ZNC bouncer. Also, try lynx/w3m on%0a%3c OpenBSD to your website, and mutt on OpenBSD to your mail server. Try to%0a%3c see if you can trigger the error before deleting the certificate, and if%0a%3c you have a valid certificate after it's deleted.%0a%3c %0a%3c !! Patching OpenBSD%0a
30 5127fd58 2021-12-17 jrmu host:1633106360=125.231.16.216
31 5127fd58 2021-12-17 jrmu author:1633105248=jrmu
32 5127fd58 2021-12-17 jrmu diff:1633105248:1633105026:=18c18%0a%3c (and last) certificate by running this command '''as root''':%0a---%0a> (and last) certificate by running this command as root:%0a
33 5127fd58 2021-12-17 jrmu host:1633105248=125.231.16.216
34 5127fd58 2021-12-17 jrmu author:1633105026=jrmu
35 5127fd58 2021-12-17 jrmu diff:1633105026:1633104716:=1c1%0a%3c On Sep 30, 2021, Let's Encrypt had [[https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire|one of their intermediate certificates expire]] (an old DST Root CA X3 certificate).%0a---%0a> On Sep 30, 2021, Let's Encrypt had [[https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire|one of their intermediate certificates expire]] (ISRG Root X1 signed by an old DST Root CA X3 certificate).%0a
36 5127fd58 2021-12-17 jrmu host:1633105026=125.231.16.216
37 5127fd58 2021-12-17 jrmu author:1633104716=jrmu
38 5127fd58 2021-12-17 jrmu diff:1633104716:1633104249:=21c21%0a%3c # awk '/END CERTIFICATE/ { cert++; } { print $0; if (cert == 2) exit;}' /etc/ssl/example.com.fullchain.pem > /etc/ssl/example.com.fullchain.pem.fixed%0a---%0a> # awk '/END CERTIFICATE/ { cert++; } { print $0; if (cert == 2) exit;} ' /etc/ssl/example.com.fullchain.pem > /etc/ssl/example.com.fullchain.pem.fixed%0a
39 5127fd58 2021-12-17 jrmu host:1633104716=125.231.16.216
40 5127fd58 2021-12-17 jrmu author:1633104249=jrmu
41 5127fd58 2021-12-17 jrmu diff:1633104249:1633102775:=17,19c17,27%0a%3c @@/etc/ssl/example.com.fullchain.pem@@. Delete the lines of the third%0a%3c (and last) certificate by running this command as root:%0a%3c %0a---%0a> @@/etc/ssl/example.com.fullchain.pem@@. Delete the last ~30 lines%0a> in the certificate:%0a> %0a> Test to see if every one of your SSL certs work. It's best to use%0a> a wide variety of web browsers, email clients, and IRC clients on preferably%0a> different operating systems. For example, an SSL cert might validate%0a> on Firefox on Debian but not on lynx on OpenBSD or mIRC on Windows.%0a> %0a> In [[https://www.openbsd.org/errata69.html|Errata for OpenBSD 6.9]], a patch%0a> is provided so that OpenBSD will verify trusted certificates first:%0a> %0a21,22c29%0a%3c # awk '/END CERTIFICATE/ { cert++; } { print $0; if (cert == 2) exit;} ' /etc/ssl/example.com.fullchain.pem > /etc/ssl/example.com.fullchain.pem.fixed%0a%3c # mv /etc/ssl/example.com.fullchain.fixed /etc/ssl/example.com.fullchain.pem%0a---%0a> $ doas syspatch%0a25,57d31%0a%3c You should repeat this for every single SSL cert you have. Then,%0a%3c if the daemon that serves the cert is running inside a chroot, make sure%0a%3c to copy the SSL cert into the chroot. For example, for ngircd:%0a%3c %0a%3c [@%0a%3c $ doas cp /etc/ssl/example.com.fullchain.pem /etc/ssl/private/example.com.key /etc/ngircd/%0a%3c $ doas chown _ngircd:_ngircd /etc/ngircd/example.com.{fullchain.pem,key}%0a%3c $ doas pkill -HUP ngircd%0a%3c @]%0a%3c %0a%3c We make sure to set the proper permissions as well as send a HUP%0a%3c signal to ngircd to cause it to reload its cert.%0a%3c %0a%3c For ZNC, we would run:%0a%3c %0a%3c [@%0a%3c $ doas cp /etc/ssl/example.com.fullchain.pem /etc/ssl/private/example.com.key /home/znc/home/znc/.znc/%0a%3c $ doas chown -R znc:znc /home/znc/home/znc/.znc/%0a%3c @]%0a%3c %0a%3c Make sure that certs are properly copied into place for all your services.%0a%3c %0a%3c Test to see if every one of your SSL certs work. It's best to use%0a%3c a wide variety of web browsers, email clients, and IRC clients on preferably%0a%3c different operating systems. For example, an SSL cert might validate%0a%3c on Firefox on Debian but not on lynx on OpenBSD or mIRC on Windows.%0a%3c %0a%3c In [[https://www.openbsd.org/errata69.html|Errata for OpenBSD 6.9]], a patch%0a%3c is provided so that OpenBSD will verify trusted certificates first:%0a%3c %0a%3c [@%0a%3c $ doas syspatch%0a%3c @]%0a
42 5127fd58 2021-12-17 jrmu host:1633104249=125.231.16.216
43 5127fd58 2021-12-17 jrmu author:1633102775=jrmu
44 5127fd58 2021-12-17 jrmu diff:1633102775:1633102620:=16,23c16,22%0a%3c Go to @@/etc/ssl/@@ where your public certificates are stored and edit%0a%3c @@/etc/ssl/example.com.fullchain.pem@@. Delete the last ~30 lines%0a%3c in the certificate:%0a%3c %0a%3c Test to see if every one of your SSL certs work. It's best to use%0a%3c a wide variety of web browsers, email clients, and IRC clients on preferably%0a%3c different operating systems. For example, an SSL cert might validate%0a%3c on Firefox on Debian but not on lynx on OpenBSD or mIRC on Windows.%0a---%0a> I fixed almost every team's SSL certs (except for maybe one or two). %0a> I ended up using just let's encrypt using a little trick: %0a> inside the .fullchain.pem, if you delete the 3rd certificate, it will %0a> then validate properly.%0a> %0a> If you'd like, check and see if SSL is verifying on a wide variety of%0a> web browsers and IRC clients.%0a
45 5127fd58 2021-12-17 jrmu host:1633102775=125.231.16.216
46 5127fd58 2021-12-17 jrmu author:1633102620=jrmu
47 5127fd58 2021-12-17 jrmu diff:1633102620:1633102485:=25c25,26%0a%3c is provided so that OpenBSD will verify trusted certificates first:%0a---%0a> is provided so that OpenBSD will verify trusted certificates first. Simply%0a> run these commands:%0a
48 5127fd58 2021-12-17 jrmu host:1633102620=125.231.16.216
49 5127fd58 2021-12-17 jrmu author:1633102485=jrmu
50 5127fd58 2021-12-17 jrmu diff:1633102485:1633095023:=10,15c10,15%0a%3c of the certificate authorities used by buypass. For this reason, do%0a%3c '''not''' use buypass for your TLS certificates.%0a%3c %0a%3c The best solution is to use Let's Encrypt issued certificates%0a%3c while also deleting the extra intermediate certificate that has expired.%0a%3c %0a---%0a> of the certificate authorities used by buypass.%0a> For this reason, do '''not''' use buypass for your TLS certificates.%0a> %0a> The best workaround continues to use the Let's Encrypt issued certificates,%0a> but also to delete the extra intermediate certificate that has expired.%0a> %0a23,31d22%0a%3c %0a%3c In [[https://www.openbsd.org/errata69.html|Errata for OpenBSD 6.9]], a patch%0a%3c is provided so that OpenBSD will verify trusted certificates first. Simply%0a%3c run these commands:%0a%3c %0a%3c [@%0a%3c $ doas syspatch%0a%3c @]%0a%3c %0a
51 5127fd58 2021-12-17 jrmu host:1633102485=125.231.16.216
52 5127fd58 2021-12-17 jrmu author:1633095023=jrmu
53 5127fd58 2021-12-17 jrmu diff:1633095023:1633095023:=1,22d0%0a%3c On Sep 30, 2021, Let's Encrypt had [[https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire|one of their intermediate certificates expire]] (ISRG Root X1 signed by an old DST Root CA X3 certificate).%0a%3c This certificate is still present in the public certificates that they issue.%0a%3c Normally, this would not be a problem, because Let's Encrypt offers%0a%3c another valid signature. However, older SSL implementations %0a%3c will reject the certificate. This includes OpenBSD 6.9 release and older%0a%3c and older versions of mIRC.%0a%3c %0a%3c Switching to another certificate authority would normally help. However, mIRC%0a%3c users have complained about validation errors. It seems they are missing one%0a%3c of the certificate authorities used by buypass.%0a%3c For this reason, do '''not''' use buypass for your TLS certificates.%0a%3c %0a%3c The best workaround continues to use the Let's Encrypt issued certificates,%0a%3c but also to delete the extra intermediate certificate that has expired.%0a%3c %0a%3c I fixed almost every team's SSL certs (except for maybe one or two). %0a%3c I ended up using just let's encrypt using a little trick: %0a%3c inside the .fullchain.pem, if you delete the 3rd certificate, it will %0a%3c then validate properly.%0a%3c %0a%3c If you'd like, check and see if SSL is verifying on a wide variety of%0a%3c web browsers and IRC clients.%0a
54 5127fd58 2021-12-17 jrmu host:1633095023=125.231.16.216
