Hello ,
I am looking OCSP validation during snmp4j TLSTM connection establishment .
To try this I have the revoked certificate (which has the OCSP URL in the certificate) in the TrustStores of SNMP4j Agent and Client application which connects using snmp4j API.
Have set the the system properties as below in Client and Agent.
System.setProperty(com.sun.net.ssl.checkRevocation,true);|
System.setProperty(ocsp.enable,true);
However the during the initial handshake the certificates get validated and connection gets established successfully .
Is there any configuration available to enable OCSP validation in SNMP4J ?
If not how are we supposed to do the OCSP validation ? As the snmp.send gets executed once the certificate is validated and we do not have the reference of Agent/client certificate to validate in Client/Agent .
Note:
I am running the OCSP server locally and verifying the certificate using openssl command returns the status as revoked(as expected) .
Hi,
I have to reproduce that, maybe there is an additional configuration during the TrustManager initialization needed, but I expect that it should be fine to support Java’s standard revocation checking.
It will probably take 2 or 3 weeks until I can report back my test results here.
Hi Vikas,
I suggest to try JRE 16 too, because there were a lot of changes and fixes on the TLS engine between version 9 and 16.
I will first try to reproduce it with the latest version by end of next week. The versions 15 and above have even better debugging output available.
Hope this helps anyway.
Best regards
Frank
Hi Frank ,
I tried with JDK 16 , still the behavior is same . Connection was successfully established even with revoked certificate.
Please let me know if you need any details w.r.t logs or the self signed certificate which I have used.
I need some more days to be able to setup a unit test for this. But I think initializing the PKIXParameters class with the key store that contains the revoked certificate does not make any sense. But I need to verify this assumption reading the JDK source code - the documentation is unclear about this.
/**
* Flag indicating whether to enable revocation check for the PKIX trust
* manager. Typically, this will only work if the PKIX implementation
* supports CRL distribution points as we do not manually setup CertStores.
*/
private static final boolean checkTLSRevocation = GetBooleanAction
.privilegedGetProperty("com.sun.net.ssl.checkRevocation");
and in the same class PKIXValidator:
/**
* Set J2SE global default PKIX parameters. Currently, hardcoded to disable
* revocation checking. In the future, this should be configurable.
*/
private void setDefaultParameters(String variant) {
if ((variant == Validator.VAR_TLS_SERVER) ||
(variant == Validator.VAR_TLS_CLIENT)) {
parameterTemplate.setRevocationEnabled(checkTLSRevocation);
} else {
parameterTemplate.setRevocationEnabled(false);
}
}
That means, maybe it works with setting the com.sun.net.ssl.checkRevocation system property to true. But that would be a non-portable solution, of course.
Therefore I am going to implement a generic revocation check that can be enabled programmatically using the SNMP4J API.
The new release will be available latest first week of November 2021, but I hope that there no problems during implementation of the revocation support function and then it could be ready one or two weeks earlier.
Hi Vikas,
Cloning is not (yet) possible, although I am working on a secure and mostly automated process for doing that in the near future.
Best regards
Frank
I used SNMP4J 3.6.0 and I don’t see the certificate validation getting failed for revoked certificate(Connection establishment successful for revoked certificate)
Have set both the properties as recommended in server side as well as client side .
I don’t see any logs related to connection establishment to OCSP server as well .
I think besides the code you quoted you need to set the PKIXRevocationChecker with TLSTM.setPKIXRevocationChecker and create such a checker like the default one available with TLSTMUtil.createDefaultPKIXRevocationChecker() because current Java version do not actually do the revocation checking unless custom revocation checkers (i.e. PKIXBuilderParameters) are used:
/**
* Creates a default revocation checker with CRL check only (no OCSP) and check is limited to end entity only.
* @return
* a simple revocation checker to be used with {@link #setPKIXRevocationChecker(PKIXRevocationChecker)}.
* @since 3.6.0
*/
public static PKIXRevocationChecker createDefaultPKIXRevocationChecker() {
CertPathBuilder cpb;
try {
cpb = CertPathBuilder.getInstance(TrustManagerFactory.getDefaultAlgorithm());
} catch (NoSuchAlgorithmException e) {
throw new RuntimeException(e);
}
PKIXRevocationChecker revocationChecker = (PKIXRevocationChecker)cpb.getRevocationChecker();
// Relaxed checking - avoid OCSP because of 33% overhead on TLS connection creation:
revocationChecker.setOptions(EnumSet.of(
PKIXRevocationChecker.Option.PREFER_CRLS, // prefer CLR over OCSP
PKIXRevocationChecker.Option.ONLY_END_ENTITY,
PKIXRevocationChecker.Option.NO_FALLBACK)); // do not fall back to OCSP
return revocationChecker;
}
Hi Frank ,
Can you please help with some sample implementation for OCSP using snmp4j ?
Some how I am ending up with same issue where the revocation check for OCSP is not happening and the connection gets established even for a revoked certificate .
Below is the procedure to where I used run the local OCS server using openssl .
#This requires the support of OpenSSL in your machine. So please install OpenSSL if it is not already installed.
An OpenSSL CA requires few files and some supporting directories to work. Follow the below commands to create that folder structure(Create the directory structure according to your openssl.cnf).
Copy the content of the openssl.cnf into a separate file. We will be using this new file as the configuration file to create certificates, certificate signing requests and etc. Here I have renamed it as validation.cnf. Add the following line under the section [ usr_cert ].
[ usr_cert ]
authorityInfoAccess = OCSP;URI:http://127.0.0.1:8080
Create a new stanza in validation.cnf as follows,
[ v3_OCSP ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = OCSPSigning
For this example, the OCSP server will be running on 127.0.0.1 on port 8080 as given in authorityInfoAccess extension.
Create a private key for root CA.
openssl genrsa -out rootCA.key 1024
Based on this key, generate a CA certificate which is valid for 10 years based on the root CA’ s private key.
Start OCSP Server. Switch to a new terminal and run,
openssl ocsp -index demoCA/index.txt -port 8080 -rsigner ocspSigning.crt -rkey ocspSigning.key -CA rootCA.crt -text -out log.txt &
Verify Certificate Revocation. Switch to a new terminal and run
openssl ocsp -CAfile rootCA.crt -issuer rootCA.crt -cert certificate.crt -url http://127.0.0.1:8080 -resp_text -noverify
This will show that the certificate status is good.
Revoke a certificate
If you want to revoke the certificate run following command
openssl ca -keyfile rootCA.key -cert rootCA.crt -revoke certificate.crt
2. Then restart the OCSP server.
openssl ocsp -index demoCA/index.txt -port 8080 -rsigner ocspSigning.crt -rkey ocspSigning.key -CA rootCA.crt -text -out log.txt &
3. Verify Certificate Revocation. Switch to a new terminal and run
openssl ocsp -CAfile rootCA.crt -issuer rootCA.crt -cert certificate.crt -url http://127.0.0.1:8080 -resp_text -noverify
This will show that the certificate status as revoked.
I do not think that a JRE will accept a OCSP server without https certificate.
But that should be reported by Java in their extended java.net.ssl debug output.
Have you checked that output? What is the reason that OCSP is not recognizing the revocation?
