openssl verify - how to verify a single combined certificate bundle file

Question

I maintain/enhance a product that uses a browser-based admin interface. We're late to the party and are only now looking to support HTTPS between browser and our backend (Apache httpd in front of Tomcat, all running on Linux). So... I'm fumbling my way thru new (to me) areas, and one of them is dealing with certificates as obtained from a certificate authority.

For testing/education purposes I obtained my own certificate from a CA - I provided them a CSR, and what I got in return were two things: (1) server.crt and (2) intermediates.crt (a file containing at least one - maybe more? - intermediate certificates)

IIUC both of these files need to be installed into our Apache. But since the Apache we ship with our product is of the newer variety (read: httpd.conf directive 'SSLCertificateChainFile' has been removed after version 2.4.8), the two files from the CA must be combined into a single file like this (with Apache 'SSLCertificateFile' pointing to that one file):

cat server.crt intermediates.crt > combined.crt

OK fine. Apache's happy.

Where I'm running into problems is how to verify the 'combined.crt' file for correctness. Since it'll be user-generated - and users screw up - I'll want to do some validation on the file. FWIW... our product completely hides Linux from the user - the user does not have access to a Linux command prompt, root, etc. EVERYTHING the user does in the way of admin'ing our product is done thru our product's front-end interface. So any answer that involves the user going to a Linux prompt is a non-starter.

I cannot figure out any way to use 'openssl' to validate that the input 'combined.crt' the user would have created from the CA-provided files (a) really contains certificates and not just some random garbage frrm a confused user, and then (b) verify that the certificates the file contains actually constitute a valid certificate chain - i.e. order of certificates in the file is correct

I understand that openssl verify ... can do what I want but the only way I've found to make it work is to specify the two CA-provided files separately...

openssl verify -CAfile intermediates.crt server.crt

I guess I could design my interface so that the user provides both files separately. And I may end up just doing that vs. expecting the user to use a text editor to combine the two files into the proper order (more work for me but easier for our user - and safer). But at this point -- dang it -- it's now become more of a learning exercise for me. Seems like there MUST be some way for 'openssl' to verify the single certificate file as required by Apache.......?

Thanks for any guidance.

Answer 1

When openssl (or at least the sub-command openssl x509) read its input, if there is more input left, it doesn't touch it, allowing to chain multiple openssl commands to process multiple combined certificates and making splitting them back easy without having to use text processing commands.

An intermediate certificate is not trusted: only root certificates usually in the OS store (the list usually provided by Mozilla, Google Microsoft & co.) are trusted. So -CAfile shouldn't be used with an intermediate certificate (even if it accepts such certificate) or it won't validate the complete chain. -trusted is to be used for real (self-signed) root certificates but is usually needed only for an internal (non-public) root CA that wasn't added to the OS store.

All intermediate certificates should be provided through the -untrusted parameter.

Using a bash shell for its convenient <() construct, turning pipe-like output into file-like parameters, which openssl supports well. I made below some repetition (combined.crt is read twice) that could probably be avoided with a better script or language, but it stayed simple.

The command becomes (requiring a bash shell):

openssl verify -untrusted <( { openssl x509 >/dev/null; cat; } < combined.crt ) <(openssl x509 < combined.crt)

First read of combined.crt discards the server certificate by a dummy use of openssl x509 and provides back (all) following intermediate certificate(s), second read of combined.crt takes the first (server) certificate and discards everything else.