OCSP validation in snmp4j TLSTM

SNMP4J
#1

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) .

image
image1193×98 5.28 KB

image

Can you please provide your inputs on this ?

#2

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.

BTW, what SNMP4J and Java version are you using?

Best regards
Frank

#3

Hi Frank ,
Thank you for the response.

I have tried the OCSP validation scenario with latest SNMP4J
> SNMP4J -3.5.1
> SNMP4J-agent-3.5.0
> JDK-9.0.4

Regards,
Vikas

#4

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

#5

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.

Regards ,
Vikas

#6

Hi Frank,
By any chance where you able to check this ?

As per the java documentation we need to use setRevocationEnabled method on PKIXParameters setting the ocsp.enable property to "true" .
https://docs.oracle.com/javase/10/security/java-pki-programmers-guide.htm#JSSEC-GUID-E6E737DB-4000-4005-969E-BCD0238B1566

image
image1373×153 22.9 KB

I did not find any code related to setRevocationEnabled in snmp4j .

So I tried adding it in TLSTMUtil but still the behavior was same (Connection was successful for revoked certificate )

image
image979×467 24 KB

Regards,
Vikas

#7

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.

#8

In the Oracle JDK 13 source code I found:

/**
 * 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.

#9

Thank you Frank.

Would we have the support for below mentioned points in next release ?

Support for OCSP (revocation check) from SNMP4J API
Support for Bouncy castle Keystore ( Support for Bouncy castle Keystore - #5 by AGENTPP ).

Can you please let us know when can we expect(approximate) the next release to be available ?

#10

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.

1 Like
#11

The revocation checking based on CRL file or OCSP is working for TLSTM in the latest SNMP4J 3.6.0-SNAPSHOT.

In any case, CRL/OSCP revocation checking will be disabled by default, because it consumes a lot of performance during handshake.

BTW, when revocation checking is switched on by

System.setProperty("com.sun.net.ssl.checkRevocation", "true");

then it seems that it cannot be switched in the same VM anymore back to “false”. Does anyone know how to work around this behaviour?

#12

Documentation on how to enable TLS certificate revocation checking with SNMP4J 3.6.0 or later can be found here:
https://doc.snmp.app/pages/viewpage.action?pageId=83525633

#13

Thank you Frank for the support .

I will run a test and update on this.

Can I clone the SNMP4J 3.6.0 source code ? If so please share the link to clone the same .

Regards,
Vikas

#14

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