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
