A lot depends on what you mean by "verify", too.  TLS endpoints should perform 
a large number of checks on certificates; some of them aren't relevant for your 
purposes, and others might not be.

For example, a TLS client such as a browser will check whether the received 
entity certificate identifies the peer it wants to connect to - generally 
checking the subjAltName extensions, and possibly falling back on e.g. the CN 
of the subject DN if the certificate isn't X.509v3. That's not relevant in your 
case.

And then there are things like CRLs and OCSP checks. If you don't care about 
those, obviously that's work you don't have to do. What about, oh, certificate 
purpose, for example? Do you care about the chain length?

So what are you checking? My guess is the list is something like this:
1. Object is a valid X.509 certificate (ASN.1 parsing doesn't show any errors, 
structure is appropriate, contains required fields...).
2. Within the validity period, as you noted in your original message.
3. Valid signature. This means you'll need the public key of the signing 
certificate, of course. Are you going to chase it all the way to the root? Do 
you care about whether the root's in some collection of trust anchors?

That's a lot simpler than verifying a peer certificate for TLS - my checklist 
for that is 11 steps, and recurses as it walks the chain. But it's still a fair 
bit of work.

Personally, for a project like this, as I harvested public keys I'd put them in 
a NoSQL key-value store, with the certificate subject DN as the key. Then I 
wouldn't have to find and parse the signing certificate for step 3, if I'd 
already stored the corresponding key.

Michael Wojcik 
Distinguished Engineer, Micro Focus 



-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Reply via email to