Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote 2 down vote favorite
1

Well I began with PKI a year ago with RFID system at school. Now I'm asked to implement this in my job. I understand most part of the idea. The doubt is about the certificate validation.

I know it has a valid date "Not before" and "Not after". Is this enough to say that the certificate is valid? This is because the certificates are changed every year and I want to be sure that the data signed was signed with a valid key. How can I implement this on Java?

The other question is about revocation, I don't understand what's it for, can anyone explain me?

share|improve this question
Just to clarify the question: are you talking about X.509 certificates, possibly outside the scope of SSL/TLS (e.g. S/MIME)? I'm not sure whether the RFID application you're talking about would use TLS. – Bruno Dec 8 '11 at 22:32
The RFID app used X.509 certs. And yes it's not about RFID app. This is a completely new project. – BRabbit27 Dec 8 '11 at 22:51

3 Answers

up vote 3 down vote accepted

Without certificate revocation, your only way of validating a certificate would be to make sure the dates are good and that the CA that signed it is trusted. What if you issued a client certificate to a user for VPN access and that certificate was misplaced or stolen? What if a server was compromised and the certificate no longer trusted? Certificate revocation allows you to "revoke" individual certificates that should no longer be accepted. When validating a certificate, the client will check the CRL (Certificate Revocation List) for a list of certificates that have been revoked to ensure that the cert is still good.

share|improve this answer
Thank you very much ! – BRabbit27 Dec 8 '11 at 21:13
glad I could help and welcome to ITSecurity! – Paul Ackerman Dec 8 '11 at 21:14
up vote 4 down vote

Certificate validation is, huh, a bit more than looking at the dates.

Have a look at RFC 5280. It would be an utter delusion to believe that you could implement certificate validation with any kind of security, and decent interoperability, if you do not read several times and wholly understand that document. A lot of crud has accumulated on the X.509-related standards, which makes implementation of certificate validation a daunting endeavour. The X.509 style guide is a must-read (although now a bit dated, it still gives the right impression about the state of things in the X.509 world).

Really, if your boss told you to implement X.509 validation, then either he mocked you, or he is seriously disconnected from reality.

Your best bet is to use some existing library which already does the job. Fortunately, Java itself comes with some code for that; look it up in the java.security.cert package. Peruse the Java PKI Programmer's Guide and the adjacent note.

Revocation is the PKI equivalent of "Whoops, sorry, disregard my previous message". It is used to declare that a given certificate shall not be used, even though all the paraphernalia of signatures and name constraints and policy trees and key usages says that everything is fine with it. Revocation status checking involves downloading potentially huge lists of revocation (CRL) and/or talking to online servers who assert the status of some certificates (OCSP); either way, it is expensive, bulky, and it will work only insofar as the corresponding Certification Authority publishes revocation information in a proper and standard-compliant way, i.e. not that often.

share|improve this answer
1  
It may be worth noting these two system properties: com.sun.net.ssl.checkRevocation and com.sun.security.enableCRLDP, which I think are false by default, although I'm not sure whether they're only applicable within the context of JSSE (and TrustManagers), or more generally to the certification path API (it would also make sense, but I only see mention of it on the JSSE Ref). In addition to the PKIX verification, the date validity also need to be checked (the cert. path API won't do it), see X509Certificate.checkValidity(...). – Bruno Dec 8 '11 at 22:24
Thanks for your info! I think I didn't express my idea correctly. For example, If I have a certificate how can I verify that this is a completely valid one? What I want to avoid is users make use of an old certificate or even a revoked one. So I assumed that verifying dates and verifying CA's signature should be enough (what Paul Ackerman said). – BRabbit27 Dec 8 '11 at 22:56
@BRabbit27, Tom is mainly giving you more implementation details on how to do what Paul said: verify the cert against your trusted CAs (via the certification path), check the dates are valid and check whatever extensions you want to check for your application (always check the ones flagged as critical or fail the verification if your app can't understand them). There's fairly good note on extensions for TLS usage here: mozilla.org/projects/security/pki/nss/tech-notes/tn3.html – Bruno Dec 8 '11 at 23:01
I would argue that what Paul Ackerman said is misleading. I just popped over here so don't have enough reputation yet to down vote, but at the very least you should verify the signatures of each certificate in the chain up to the root cert and should verify the root cert itself. The only time when verification of the root cert gets to be an issue is when Java doesn't include it in its trusted certs by default (Equifax isn't in there, for example). In theory if everything else passes, checking a revocation list makes sense, but only after doing all that lighter weight work. – adamfisk Aug 27 '12 at 23:34
up vote 4 down vote

In addition to what @Tom Leek's said about the certification path API, it seems that you're talking about "TLS certificates", which I presume implies you may be using your X.509 certificate within the scope of TLS.

To do this as part of Java's TLS stack (JSSE), you can use the existing X509TrustManager infrastructure. I must admit I'm not sure whether it verifies against RFC 5280 or RFC 3280, its older specification (it probably depends on the version of Java you're using). I'm assuming Sun/Oracle JRE 6, but the implementation will vary depending on the security providers installed. This is a wrapper on top of the certification path API already mentioned.

Here is an example that initializes a TrustManagerFactory with null: it will use the default values for the trust anchors. The following will give you the trust managers:

TrustManagerFactory factory = TrustManagerFactory.getInstance("PKIX");
factory.init((KeyStore)null);
TrustManager[] trustManagers = factory.getTrustManagers();

The check* methods of the trust manager throw a CertificateException when something has failed. It also checks the date validity.

The trust managers can be used to initialize an SSLContext, which can then be used to initialize an SSLSocket (via the factory) or SSLEngine. By default, SSLSocketFactory uses the default SSLContext, itself initialized with a number of default values.

You can also create your own TrustManager if you need to check further extensions for your application and/or relax certain rules. (For example, I've written a small library to wrap existing trust managers and accept other forms of certificates, such as proxy certificates (RFC 3820 -- not 3280).)

For verifying specific extensions, I'd recommend using BouncyCastle, since it provides data structures to deal with ASN.1 and so on.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.