Nah, openssl verify expects root-first order.
Interesting … OpenSSL’s handshake verification differs from its separate verification function—which cP uses to determine whether we need to grab a new certificate, which is why you folks are seeing a glut of requests from cP boxes.
I’m researching whether that dedicated verification logic can be configured to behave the same way as connection verification.
2 Likes
OK, then if both fail, hmm...
You may need to replace the cross-signed X1 with the self-signed X1
[since your checks aren't short-circuiting the validation at X1 - as expected]
OK, then if both fail, hmm...
Actually, no, the verification succeeds if I discard the non-self-signed ISRG Root X1. That happens because, when openssl verify receives that chain, it looks in its roots for ISRG Root X1 and finds it.
So do you have a workaround or do you still have an unsolved problem?
[sorry I'm likely in the wrong MODE - long day]
sorry I'm likely in the wrong MODE - long day
I can only imagine …
I don’t have a workaround and definitely still have an unsolved problem—or, rather, 2 of them:
- Our SSL provisioning service uses OpenSSL’s verify, which is reporting the chains as invalid in CentOS 7 and CloudLinux 6. So cPanel boxes are hammering Let’s Encrypt’s servers, in response to which apparently LE has rate-limited the client library that cPanel servers use. This, of course, complicates testing of potential solutions.
- Our bigger problem, though, is that mail clients are balking at the cert chain that now points to an expired root. We’re looking at some solution whereby we replace all of the cert chains with the CA Issuers chain, which points to the self-signed ISRG Root X1. That’ll break other clients, of course, but c’est la vie. We’ll also need to update our SSL provisioning logic to request/use the short chain.
For what it’s worth: as an integrator, I find it hard to grasp why there are “two conflicting defaults” in play: one being the cert chain that the ACME service returns, the other being the one from the CA Issuers chain.
1 Like
On #1, have you tried?:
openssl verify -partial_chain file.pem
An update: macOS’s openssl fails the chain, even on a normal connection.
/usr/bin/openssl s_client -showcerts -connect test7.shooltz.net:443 -servername test7.shooltz.net
CONNECTED(00000005)
depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
---
> /usr/bin/openssl version
LibreSSL 2.6.5
I’m told LibreSSL 2.8.3 shows the same behaviour.
Please forgive if this is something that’s been posted multiply elsewhere, but what is the API control for downloading the shorter certificate chain?
@FGasper No worries. I presume you to mean which clients offer the chain selection. I quoted ezekial from earlier in this thread for reference.
Adding to that,
Certbot version 1.12 and later have this:
--preferred-chain PREFERRED_CHAIN
Set the preferred certificate chain. If the CA offers
multiple certificate chains, prefer the chain whose
topmost certificate was issued from this Subject
Common Name. If no match, the default offered chain
will be used. (default: None)
Certbot offered this before 1.12 but it did not work right for selecting the shorter ISRG Root X1 chain until 1.12.
I also recently tested getssl (a bash client) which has a similar PREFERRED_CHAIN configuration option.
https://github.com/srvrco/getssl
I mention these two as I have personal experience with using this feature with both of them.
I quickly browsed the perl acme client you mentioned but saw no similar feature available in it.
3 Likes
My turn to apologize in case this has been asked and answered. But, for your openssl verify problems are those only older openssl versions?
If so, would the -trusted_first option allow it to succeed? It just requires ISRG Root X1 to be trusted (not necessarily the root). You can read the details here under Workaround 2:
https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/
1 Like
No, I need the actual API controls, not client controls. Because I need to update that Perl library. 
To my memory of playing with openssl verify in ages past, how to get it to do what one actually wanted was rather unintuitive. Intermediates needed to be separately listed as "untrusted extra certificates" or the like and not as trusted CAs themselves. You like, almost needed to know how to build the chain already, to tell it how to verify it and it could tell you whether the way you set it up in fact worked. But it may have just been me not understanding how to use it.
2 Likes
I’ve not been able to make this work, alas.
But it doesn’t really matter since we need the short chain regardless.
1 Like
@petercooperjr I used the trusted_first today on a couple chains for this specific problem and it worked as openssl advertises 
Using 1.0.2k
1 Like
You'll want to review RFC 8555 section 7.4.2 for details on how alternate chains are retrieved via ACME. Here's the crux of it:
The server MAY provide one or more link relation header fields [RFC8288] with relation "alternate". Each such field SHOULD express an alternative certificate chain starting with the same end-entity certificate. This can be used to express paths to various trust anchors. Clients can fetch these alternates and use their own heuristics to decide which is optimal.
5 Likes
Drive in the inner lane.
For her that one what is near to the edge of the road.
2 Likes
Let me tell you how to get there... You know the corner of X and Y right?
OK, just turn left there and go straight...
Meanwhile... "X and Y" is a four-way intersection with four corners and four possible lefts!
So which way is left? [I just don't speak their language]
2 Likes
The answer is YES and NO. 
2 Likes
You failed too!
Her answer was NO and YES! 
2 Likes