Hi Frank,

Thanks very much for the quick response. Currently I am just in the researching 
phase to verify the functionality of snmp4j over TLS. I can envision that there 
will be definitely some sort of certificate management scheme for the devices 
on the server side.

At the moment, the two issues that I raised in my previous email are preventing 
me from proceeding further with the prototyping effort. Do you have any pointer 
or hint on how to work through these two issues?

Thanks again in advance!

Nick
 
On 11/14/17, 3:20 PM, "Frank Fock" <[email protected]> wrote:

    Hi Nick,
    
    When using TLSTM, you are not doing TLS alone. TLSTM is integrated to the 
SNMPv3 transport model and uses the security name too. Thus, the security name 
you use in SNMP, is mapped to the certificates (roughly). For this mapping, 
more than one approach exists. Is that supported (TLSTM including 
security-name-to- certificate mapping) on the server side?
    
    If yes, you can use the SnmpConfigurator in SNMP4J’s util package to 
configure your Snap session.
    
    Best regards,
    Frank  
    
    
    > On 14. Nov 2017, at 20:45, Nick Chang <[email protected]> 
wrote:
    > 
    > Hi Frank,
    > 
    > I made some further progress by importing DeviceCert into the keystore 
and then also corrected the subject name is  the call 
securityCallback.addAcceptedSubjectDN(<subject name>).
    > Now I can see the SSL handshaking successful. However, I still experience 
following two issues:
    > 
    > 1. Occasionally, the handshaking failed and got such an error during 
“ServerHello, TLSv1.2” phase.
    > javax.net.ssl.SSLException: Unsupported record version Unknown-26.31
    >   at sun.security.ssl.InputRecord.checkRecordVersion(InputRecord.java:552)
    >   at 
sun.security.ssl.EngineInputRecord.bytesInCompletePacket(EngineInputRecord.java:113)
    >   at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:868)
    >   at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781)
    >   at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
    >   at org.snmp4j.transport.TLSTM$ServerThread.readMessage(TLSTM.java:1483)
    > 
    > 2. All the requests are timed out and the response.getResponse() is 
always null. I set the timeout very high, 1 minute, and retries to 3. The same 
device can respond to snmpget command without any delay. Below is the code 
snippet of sending a request
    >            PDU pdu = new ScopedPDU();
    >            pdu.add(new VariableBinding(new OID(someOid),new 
OctetString("Hello")));
    >            pdu.setType(PDU.GET);
    >            ResponseEvent response = snmp.send(pdu, ct);
    >            logger.debug("Response: {} ", response.getResponse());
    > 
    > Any suggestion on further trouble shooting this is greatly appreciated!
    > 
    > Thanks a lot in advance,
    > 
    > Nick
    > 
    > On 11/13/17, 10:07 PM, "Nick Chang" <[email protected]> 
wrote:
    > 
    >    Hi Frank,
    > 
    >    Thanks for your reply. I did use 
“System.setProperty("javax.net.debug", "all");” to view the handshaking traffic 
between the device and the client. I found out that I need to add the following 
lines to get it working with Java 1.8 since it supports TLSv1.2 by default
    > 
    >                String[] tlsProtocols = new String[]{"TLSv1.2"};
    >                ((TLSTM) transport).setTlsProtocols(tlsProtocols);
    > 
    >    I currently got stuck at *** ServerHello, TLSv1.2 step, the error is
    >    “sun.security.validator.ValidatorException: PKIX path building failed: 
sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
valid certification path to requested target”
    > 
    >    I think that it might have something to do with the incorrect setup of 
keystore and truststore that I have, but I have not been able to figure out 
what exactly I should construct them to make it pass this error.
    > 
    >    Here are certificates and keys that I have, 
    >    • CACert
    >    • DeviceCert: whose alias is “device”
    >    • ClientCert: whose alias is “client”
    >    • DeviceKey: private key of device
    >    • ClientKey : private key of client
    >    which I could connect to the device by using such a command: 
    >    openssl s_client -connect <Device’s IPv6 Addr>:<port no> -tls1_2 -cert 
ClientCert -CAfile CACert -key ClientKey
    > 
    >    The keystore is created by adding ClientCert,  CACert and ClientKey 
together.
    > 
    >    Then I imported the CACert and DeviceCert into Java’s default 
truststore in JAVA_HOME/lib/security/cacerts
    > 
    >    And in the client code, I have            
    > 
    >    CertifiedTarget ct = new CertifiedTarget(new OctetString(“device”));
    > 
    >    and 
    > 
    >    securityCallback.addLocalCertMapping(ct.getAddress(), “client”);
    > 
    >    Any pointer on what keystore and truststore should be and the correct 
way to construct CertifiedTarget and use securityCallback.addLocalCertMapping() 
is greatly appreciated.
    > 
    >    Thanks very much,
    > 
    >    Nick
    > 
    >    On 11/13/17, 6:34 PM, "Frank Fock" <[email protected]> wrote:
    > 
    >        Hi Nick,
    > 
    >        Do you have enabled debug logging? This should give more detailed 
information about the TLS handshake.
    > 
    >        Best regards,
    >        Frank
    > 
    > 
    >> On 11. Nov 2017, at 17:14, Nick Chang <[email protected]> 
wrote:
    >> 
    >> Hi Frank,
    >> 
    >> I am using snmp4j to build a client with functionality similar to that 
of net-snmp’s snmpget. The device is using IPv6 and configured with TLS.
    >> I followed the instruction carefully given on this page, 
https://oosnmp.net/confluence/pages/viewpage.action?pageId=3834144, but the 
response always comes back with null from the device.
    >> Do you have any suggestion how I should trouble this further. I am using 
JDK 1.8 and snmp4j v2.5.6
    >> 
    >> Thanks,
    >> 
    >> Nick
    >> 
    >> 
    >> _______________________________________________
    >> SNMP4J mailing list
    >> [email protected]
    >> https://oosnmp.net/mailman/listinfo/snmp4j
    > 
    > 
    > 
    > 
    > 
    
    

_______________________________________________
SNMP4J mailing list
[email protected]
https://oosnmp.net/mailman/listinfo/snmp4j

Reply via email to