You should be able to do cat chain.pem cert.pem | openssl verify. If you don’t have the appropriate ca-certificates set up on your system you may need to add -CAfile or -CApath pointing to something that includes (at a minimum) the IdenTrust DST Root X3.
Thanks. The certs are installed on some machines, not all. I was hoping there was some command to just show a relation of the two certificates (and not verifying the entire chain). I guess I don’t have a choice in this though.
Ah, got it. The command you posted (openssl verify -CAfile chain1.pem cert1.pem) should work for that AFAICT. Maybe you can post chain1.pem and cert1.pem and we can see if there’s really a problem between them?
I don’t think that’s the case. For instance, I just used that command to verify a fake root / intermediate pair that I generated locally, with no relationship to any trusted CA. It worked for me. Again, I’d be happy to help debug if you’d like to provide the relevant certs.
This is roughly correct - when validating certificates, clients check that (Subject, Subject Key Identifier) match (Issuer, Authority Key Identifier) in the issuer. Note that Subject Key Identifier and Authority Key Identifier are generally hashes of the respective keys, not hashes of the Issuer or Subject.
Also, I’d definitely recommend against parsing the output of OpenSSL to do this matching manually.
I’m in the process of releasing my client/toolkit (it’s largely done and I’d be happy privately share the github url), and I’m parsing the output of openssl to pull out this information (and some others) to ensure certs are trafficked into the system correctly. The certs and all their data are stored in SQL and searchable/referenced and it’s working pretty nice. I’m parsing the output of openssl to pull out:
subject & hash
issuer & hash
modulus (and also piping it through an md5)
My toolkit is also piping the certs into OpenSSL for various transformations.
It’s working pretty well.
The reason why I’m doing this, is because we’re releasing a social media product that lets people use custom domains. In order to make everything line up behind load balancers etc we needed a sql datastore, and in order to serve the right certs we needed to use some lua hooks in nginx/openresty.
Hm, you’re right that it seems to have to do with the locally installed root certificates. I though -CAfile would override the use of the default installed root certificates, but I was able to reproduce the same errors you get by adding -CApath - to specifically break the default path to installed roots. I have to admit at this point that I’m stumped! OpenSSL’s command line is pretty arcane.
In general, parsing command output that’s not specifically formatted is risky, since it may change. But on second look, it appears you’re using commands that explicitly extract that data you’re interested in, so probably this is fine. But if there are any x509 bindings in the language you’re working in, those might provide a more stable API.