One time I called a restaurant and asked if they were the one on East side of I5 or the West side of I5,
since they had one on each side of I5 there. The person who answered the telephone told me that depends
if I am coming down from Seattle or up from Los Angles. The moral is that I do not know how to ask questions clearly and succinctly.
3 Likes
I missed that class too. 
2 Likes
That's not accurate. /docs/man1.1.1/man1/openssl-verify.html
-untrusted file
A file of additional untrusted certificates (intermediate issuer CAs) used to construct a certificate chain from the subject certificate to a trust-anchor. The file should contain one or more certificates in PEM format. This option can be specified more than once to include untrusted certificates from multiple files.
certificates
One or more certificates to verify. If no certificates are given, verify will attempt to read a certificate from standard input. Certificates must be in PEM format.
...
The lookup first looks in the list of untrusted certificates and if no match is found the remaining lookups are from the trusted certificates. The root CA is always looked up in the trusted certificate list: if the certificate to verify is a root certificate then an exact match must be found in the trusted list.
In other words, verify doesn't expect its certificates parameter to contain a fullchain.pem file. Instead it tries to verify each entry in certificates separately.
What you want is to put the chain in an "untrusted" file and the leaf certificate in its own file. For instance:
fg.txt (1.6 KB)
untrusted.txt (3.7 KB)
Then run this:
$ openssl verify -trusted_first -CAfile /etc/ssl/certs/ca-certificates.crt -untrusted untrusted.txt fg.txt
fg.txt: OK
If you do this, I don't think you need to do anything involving a change to use the short chain.
8 Likes
Thank you very much for that investigation! I did realize last night that I was “holding it wrong”.
I still need to futz with the actual OpenSSL API; for some reason it doesn’t seem to behave as I’d expect.
We did last night push out an auto-fix that migrated everyone to the short chain, and we’re about to push out a quick-fix that prefers it for new certificate installations. With more time to investigate this over the next few days we might migrate back if we can find a more-compatible arrangement that doesn’t cause such a ruckus as happened yesterday.
3 Likes
Good to know. The long chain is the better option in terms of what you configure for your customer websites to serve to the public. Serving the short chain will produce lots of warnings from old Android devices (<7.1). But given that your current implementation of self-check is tied up with what you serve, and breaks with the long chain, I can see how this is a useful short term fix. I encourage you to get back to the long chain (by default) as soon as you can though.
4 Likes
Oh, also I should mention: you don't need to reissue for each switch between short chain and long chain. You can simply iterate over all certificates you have on disk and either delete or add the cross-sign. That will be much more efficient and faster, on both your side and ours.
5 Likes
ACME clients should have an option for that, without renewal of course.
5 Likes
Yup, that’s what we’ll do.
2 Likes
Some already do. 
8 Likes
Show off! - LOL
Clap on!
Clap off!
[The clapper (chain switcher)]
2 Likes
It's too bad you weren't speaking Guugu Yimithirr or Tzeltal, which reportedly routinely use absolute (like north/south/east/west) rather than egocentric (like left/right/forward/backward) directions in almost all circumstances.
https://pure.mpg.de/rest/items/item_66622_3/component/file_66623/content?download=true
4 Likes
Guess I should learn those languages. 
2 Likes
I find that GnuTLS certtool is sometimes easier to use.
# certtool --verify-chain --infile fullchain.pem
Note that no verification profile was selected. In the future the medium profile will be enabled by default.
Use --verify-profile low to apply the default verification of NORMAL priority string.
Subject: CN=R3,O=Let's Encrypt,C=US
Issuer: CN=ISRG Root X1,O=Internet Security Research Group,C=US
Signature algorithm: RSA-SHA256
Output: Not verified. The certificate is NOT trusted. The certificate issuer is unknown.
Subject: CN=R3,O=Let's Encrypt,C=US
Issuer: CN=ISRG Root X1,O=Internet Security Research Group,C=US
Checked against: CN=R3,O=Let's Encrypt,C=US
Signature algorithm: RSA-SHA256
Output: Verified. The certificate is trusted.
Subject: CN=wiki.tnonline.net
Issuer: CN=R3,O=Let's Encrypt,C=US
Checked against: CN=R3,O=Let's Encrypt,C=US
Signature algorithm: RSA-SHA256
Output: Verified. The certificate is trusted.
Chain verification output: Verified. The certificate is trusted.
4 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.