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
null: it will use the default values for the trust anchors. The following will give you the trust managers:
TrustManagerFactory factory = TrustManagerFactory.getInstance("PKIX");
TrustManager trustManagers = factory.getTrustManagers();
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.