The Client Certificates security extensions continue to receive improvements in this release. In previous releases (July and September 2021) we added Client Certificate Authentication improvements, giving the ability to define multiple TrustStores and implement a SPI to allow developers to perform additional checks on the Client Certificate.
Previously, any Client Certificate that is used and matched within the KeyStore was accepted, even when the certificate was expired. Starting in the October 2021 releases (Payara Community 5.2021.8 and Payara Enterprise 5.32.0), using the newly developed SPI, we have implemented an additional check when using the Client Certificate authentication option to ensure the certificate is valid.
The Custom Client Certificate Validation allows you to perform extra checks in addition to verifying that the certificate is present in the TrustStore.
Using the SPI, you could perform a check on the validity date, and use the Online Certificate Status Protocol (OCSP) to validate the certificate when it has a Certificate Revocation List entry (CRL). Or, you can lookup the DN name in a database, and determine based on the information in the database if the certificate is still accepted.
Note: You'll need to first activate the new validity check on Client Certificates if you're using Payara Enterprise, as we wanted to maintain the backward compatibility. Use the following asadmin command to do this:
asadmin set configs.config.<config-name>.security-service.auth-realm.certificate.property.certificate-validation=true
How to Create a Custom Client Certificate Validation
When you want to implement a custom validation, you first need to implement the
fish.payara.security.client.ClientCertificateValidator interface and define your class through the ServiceLoader mechanism.
To make the
ClientCertificateValidator interface available in your application, add the
payara-api artifact to your application with <scope>provided</scope>. If you're using Maven, you can add the following snippet if it's not already defined:
After you have made the interface available, you can implement it in your application.
The most important parameter is the
principal parameter which contains the user information contained in the Client Certificate presented in the request.
The Certificate itself is in the last parameter, and if you want access to the
Subject for this validation, it is passed in as the first parameter.
When you return
true as the method result, the processing of the request continues. If false is returned, a
LoginException is thrown resulting in a status 401 for the request.
This class is loaded through the Java ServiceLoader mechanism. Make sure you have the following file. META-INF/services/fish.payara.security.client.ClientCertificateValidator containing the fully qualified name of your implementation.
Certificate Valid Check
Based on the generic Custom Validation capabilities, we have implemented a check, as available within the JVM itself, on the validity of certificate. When active, the method
java.security.cert.X509Certificate#checkValidity() is called to determine if the certificate is valid.
Certificate Valid Check is active by default in Payara Community but not for Payara Enterprise.