- Java validating a certificate
- Constructor Summary
- Method Summary
- Methods inherited from class java.lang.Object
- Constructor Detail
- CertPathValidator
- Method Detail
- getInstance
- getInstance
- getInstance
- getProvider
- getAlgorithm
- validate
- getDefaultType
- getRevocationChecker
- Implementing X509 Certificate Validation in Java: A Step-by-Step Guide
- Overview
- Importance
- Requirements
- Dependencies
- Project Code
- Class CertPathValidator
Java validating a certificate
A class for validating certification paths (also known as certificate chains). This class uses a provider-based architecture. To create a CertPathValidator , call one of the static getInstance methods, passing in the algorithm name of the CertPathValidator desired and optionally the name of the provider desired. Once a CertPathValidator object has been created, it can be used to validate certification paths by calling the validate method and passing it the CertPath to be validated and an algorithm-specific set of parameters. If successful, the result is returned in an object that implements the CertPathValidatorResult interface. The getRevocationChecker() method allows an application to specify additional algorithm-specific parameters and options used by the CertPathValidator when checking the revocation status of certificates. Here is an example demonstrating how it is used with the PKIX algorithm:
CertPathValidator cpv = CertPathValidator.getInstance("PKIX"); PKIXRevocationChecker rc = (PKIXRevocationChecker)cpv.getRevocationChecker(); rc.setOptions(EnumSet.of(Option.SOFT_FAIL)); params.addCertPathChecker(rc); CertPathValidatorResult cpvr = cpv.validate(path, params);
The static methods of this class are guaranteed to be thread-safe. Multiple threads may concurrently invoke the static methods defined in this class with no ill effects.
However, this is not true for the non-static methods defined by this class. Unless otherwise documented by a specific provider, threads that need to access a single CertPathValidator instance concurrently should synchronize amongst themselves and provide the necessary locking. Multiple threads each manipulating a different CertPathValidator instance need not synchronize.
Constructor Summary
Creates a CertPathValidator object of the given algorithm, and encapsulates the given provider implementation (SPI object) in it.
Method Summary
Returns the default CertPathValidator type as specified by the certpathvalidator.type security property, or the string «PKIX» if no such property exists.
Returns a CertPathChecker that the encapsulated CertPathValidatorSpi implementation uses to check the revocation status of certificates.
Methods inherited from class java.lang.Object
Constructor Detail
CertPathValidator
protected CertPathValidator(CertPathValidatorSpi validatorSpi, Provider provider, String algorithm)
Creates a CertPathValidator object of the given algorithm, and encapsulates the given provider implementation (SPI object) in it.
Method Detail
getInstance
public static CertPathValidator getInstance(String algorithm) throws NoSuchAlgorithmException
Returns a CertPathValidator object that implements the specified algorithm. This method traverses the list of registered security Providers, starting with the most preferred Provider. A new CertPathValidator object encapsulating the CertPathValidatorSpi implementation from the first Provider that supports the specified algorithm is returned. Note that the list of registered providers may be retrieved via the Security.getProviders() method.
getInstance
public static CertPathValidator getInstance(String algorithm, String provider) throws NoSuchAlgorithmException, NoSuchProviderException
Returns a CertPathValidator object that implements the specified algorithm. A new CertPathValidator object encapsulating the CertPathValidatorSpi implementation from the specified provider is returned. The specified provider must be registered in the security provider list. Note that the list of registered providers may be retrieved via the Security.getProviders() method.
getInstance
public static CertPathValidator getInstance(String algorithm, Provider provider) throws NoSuchAlgorithmException
Returns a CertPathValidator object that implements the specified algorithm. A new CertPathValidator object encapsulating the CertPathValidatorSpi implementation from the specified Provider object is returned. Note that the specified Provider object does not have to be registered in the provider list.
getProvider
getAlgorithm
validate
public final CertPathValidatorResult validate(CertPath certPath, CertPathParameters params) throws CertPathValidatorException, InvalidAlgorithmParameterException
Validates the specified certification path using the specified algorithm parameter set. The CertPath specified must be of a type that is supported by the validation algorithm, otherwise an InvalidAlgorithmParameterException will be thrown. For example, a CertPathValidator that implements the PKIX algorithm validates CertPath objects of type X.509.
getDefaultType
Returns the default CertPathValidator type as specified by the certpathvalidator.type security property, or the string «PKIX» if no such property exists. The default CertPathValidator type can be used by applications that do not want to use a hard-coded type when calling one of the getInstance methods, and want to provide a default type in case a user does not specify its own. The default CertPathValidator type can be changed by setting the value of the certpathvalidator.type security property to the desired type.
getRevocationChecker
Returns a CertPathChecker that the encapsulated CertPathValidatorSpi implementation uses to check the revocation status of certificates. A PKIX implementation returns objects of type PKIXRevocationChecker . Each invocation of this method returns a new instance of CertPathChecker . The primary purpose of this method is to allow callers to specify additional input parameters and options specific to revocation checking. See the class description for an example.
Submit a bug or feature
For further API reference and developer documentation, see Java SE Documentation. That documentation contains more detailed, developer-targeted descriptions, with conceptual overviews, definitions of terms, workarounds, and working code examples.
Copyright © 1993, 2023, Oracle and/or its affiliates. All rights reserved. Use is subject to license terms. Also see the documentation redistribution policy.
Implementing X509 Certificate Validation in Java: A Step-by-Step Guide
Unlock the power of secure communication with Java! Learn how to implement X509 certificate validation simply and straightforwardly, step-by-step.
Overview
An X.509 certificate is a digital certificate used to verify a particular entity’s identity, such as a website or an individual. X.509 certificates are widely used in various applications, including secure communication protocols like HTTPS, SSL, and TLS. An X.509 certificate contains several pieces of information, including the identity of the entity being verified, the public key that is associated with that entity, and various other pieces of metadata that provide additional information about the certificate itself.
Importance
One of the key benefits of X.509 certificates is that they allow entities to authenticate themselves to other parties securely and reliably. This can help to prevent various types of attacks, including man-in-the-middle attacks, where an attacker intercepts and modifies communication between two parties to steal sensitive information. Overall, X.509 certificates play a critical role in modern security infrastructure and are essential to many different types of secure communication protocols.
Requirements
Dependencies
This project uses the following dependencies.
- bcpkix-jdk15on — certificate revocation check
- spring-boot-starter-test (for testing)
- lombok (for logging)
- Certificates from https://www.digicert.com/kb/digicert-root-certificates.htm
Project Code
The certificate validation process.
To implement the validation, we will introduce a bean where we can define the:
- Certificate that we are validating
- The pem file that we can cross-check #1
- Root certificate to check if the certificate is already revoked
Let’s examine the code.
The CertificateBundle class is just a simple Java bean.
@Getter @Setter @Builder public class CertificateBundle < // Certificate extracted from the message private X509Certificate certificate; // Certificate loaded from the application must match the certificate private X509Certificate confirmationCertificate; // RootCertificate of the certificate private X509Certificate rootCertificate; >
To validate the certificate expiration, we need to extract the X509Certificate object and perform a time comparison against the value of getNotAfter(). Here, we’re making sure that the current date is greater than the certificate’s expiry date.
Date expiresOn = cert.getNotAfter(); Date now = new Date(); if (now.getTime() > expiresOn.getTime())
Comparing digital signature against a PEM file. In most fintech applications, there is a need to sign the message before sending it to another service. Upon receiving the message, the server needs to extract the public certificate embedded in it and compare it to a PEM file. This PEM file is a public key of the private key certificate used to sign the message.
boolean match = Arrays.equals(cert1.getPublicKey().getEncoded(), cert2.getPublicKey().getEncoded()); if (!match)
And finally, we do the revocation check. This process allows us to know whether a website’s certificate is trustworthy or not. It uses the root certificate that we used for signing as the trust anchor.
try < Listcerts = Collections.singletonList(cb.getCertificate()); CertificateFactory cf = CertificateFactory.getInstance("X509"); CertPath cp = cf.generateCertPath(certs); // load the root CA cb X509Certificate rootCACert = cb.getRootCertificate(); // init trusted certs TrustAnchor ta = new TrustAnchor(rootCACert, null); Set trustedCerts = new HashSet<>(); trustedCerts.add(ta); // init PKIX parameters PKIXParameters params = new PKIXParameters(trustedCerts); // load the CRL params.addCertStore(CertStore.getInstance(«Collection», new CollectionCertStoreParameters(getX509Crls(cf, getCrl(cb.getCertificate()))))); // perform validation CertPathValidator cpv = CertPathValidator.getInstance(«PKIX»); PKIXCertPathValidatorResult cpvResult = (PKIXCertPathValidatorResult) cpv.validate(cp, params); X509Certificate trustedCert = cpvResult.getTrustAnchor().getTrustedCert(); if (trustedCert == null) < log.error("Trusted certificate not found"); throw new CertificateException("Trusted certificate not found"); >else
Class CertPathValidator
This class uses a provider-based architecture. To create a CertPathValidator , call one of the static getInstance methods, passing in the algorithm name of the CertPathValidator desired and optionally the name of the provider desired.
Once a CertPathValidator object has been created, it can be used to validate certification paths by calling the validate method and passing it the CertPath to be validated and an algorithm-specific set of parameters. If successful, the result is returned in an object that implements the CertPathValidatorResult interface.
The getRevocationChecker() method allows an application to specify additional algorithm-specific parameters and options used by the CertPathValidator when checking the revocation status of certificates. Here is an example demonstrating how it is used with the PKIX algorithm:
CertPathValidator cpv = CertPathValidator.getInstance("PKIX"); PKIXRevocationChecker rc = (PKIXRevocationChecker)cpv.getRevocationChecker(); rc.setOptions(EnumSet.of(Option.SOFT_FAIL)); params.addCertPathChecker(rc); CertPathValidatorResult cpvr = cpv.validate(path, params);
The static methods of this class are guaranteed to be thread-safe. Multiple threads may concurrently invoke the static methods defined in this class with no ill effects.
However, this is not true for the non-static methods defined by this class. Unless otherwise documented by a specific provider, threads that need to access a single CertPathValidator instance concurrently should synchronize amongst themselves and provide the necessary locking. Multiple threads each manipulating a different CertPathValidator instance need not synchronize.