I am working on connecting to SNMP4j agent with TLS connection, where I am able to successfully connect using Subject DN or by passing Agent certificate finger print in CertifiedTarget , but not able to connect using subjectAlternativeName
it fails as the fingerprint is returned as null in checkServerTrusted method of TlsTrustManager
fingerprint = ((CertifiedIdentity)tmStateReference.getTarget()).getServerFingerprint();
An obvious error in your call to addSecurityNameMapping is that the second to last parameter (the “data”) is the empty OctetString. Instead of that it should contain the DN (e.g. “localhost”).
I am using the latest SNMP4j -3.5.1
Have tried the below mentioned input parameters, however the error remains the same .
securityCallback.addSecurityNameMapping(new OctetString(), SecurityNameMapping.CertMappingType.SANDNSName, new OctetString("localhost"), null);
securityCallback.addSecurityNameMapping(new OctetString(), SecurityNameMapping.CertMappingType.SANDNSName, new OctetString("localhost"), new OctetString("agntcrt"));
securityCallback.addSecurityNameMapping(new OctetString(), SecurityNameMapping.CertMappingType.SANDNSName, new OctetString("DNS:localhost"), null)
Using JRE 9 , tried in JRE 16 as well but the error remains the same.
I ran the wrong unit test so that I tested the server verification instead of the client side verification.
To get the client side verification working with the certified target, you need to add the DNS hostname pattern you want to accept as server in the “identity” parameter for the certified target:
new CertifiedTarget(new OctetString("localhost"),...)
Hope this helps. This unexpected difference for DNS SAN mapping is necessary because you might want to use different patterns for different targets but still use the same security callback.
Thank you for sharing the code snippet . Even in my case it works fine when I have addAcceptedIssuerDN and addSecurityNameMapping
But it does not work while having only the SAN or addSecurityNameMapping.
It is possible to have only the addSecurityNameMapping and not have addAcceptedIssuerDN and make it work ?
If possible can you please share the initialization of below variables which are in the code snippet ?
tlstmCR and tlstmCS
Are you using the TLSTMExtendedTrustManager as TLSTM does by default?
For me the test works even if accepted issuer DN and accepted subject DN are not set (= empty) in the SecurityCallback. But from my code inspection, this works only, if the TLSTMExtendedTrustManager is actually used.