If your goal is to improve performance, you want to get into checking on certificates BEFORE the SSL handshake is completed. Negotiating the symmetric key for the connection is the computationally expensive part of establishing a connection.
You can check just about anything in a certificate AFTER the SSL connection is established. The trick from a performance perspective is getting into a state where you can bounce the connection BEFORE the handshake is completed.
I have two thoughts:
1 - See what SSL libraries you can use in your server, and what constraints they will let you do. Usually SSL libraries will let you:
- limit the connection to trusted certificates
- check for current validity
Some higher end libraries will also let you do an OCSP check or CRL check to verify current status.
Most libraries will let you hook in and write your own verification - but you have to really dig into the details and figure out if it's letting you do verification before or after the connection is established.
2 - Another trick for SSL performance improvement is to set your servers so that they reuse shared keys from previous sessions. This eliminates the setup cost when the same two points re-establish the connection. If you don't have secure storage, this will put your system at risk. But it may be an acceptable trade if you protect the key store correctly.
This depends greatly on your environment -- #2 is not a win in an environmnet with a LOT of connections - you won't be able to recycle the connections enough to justify storing information.