Storing client X509CertPath chain on TlsEndpointContext

[AlexITC]

• branch: 2.0.x
• commit: 05b12ed

Currently, on NettyContextUtils#buildEndpointContext, the X500Principal is being extracted, it would be useful to have the whole certificate chain, this could be retrieved from SSLSession#getPeerCertificateChain().

I have a working code for this and I wonder if you are willing to merge it.

On NettyContextUtils we do this instead of storing the X500Principal:

try {
  X509Certificate[] peerCertificateChain = sslSession.getPeerCertificateChain();
  sslSession.getPeerCertificateChain()
  if (peerCertificateChain != null && peerCertificateChain.length != 0) {
    java.security.cert.CertPath javaCertPath = toJavaCertPath(peerCertificateChain);
    principal = new X509CertPath(javaCertPath);
  }
} catch (Exception e) {
  // do nothing
}

And we'll need some helper methods:

static java.security.cert.CertPath toJavaCertPath(javax.security.cert.X509Certificate[] javaxCertificatePath) throws Exception {
  List<java.security.cert.Certificate> javaCertificatePath = new LinkedList<>();
  for (javax.security.cert.X509Certificate javaxCertificate : javaxCertificatePath) {
    java.security.cert.Certificate javaCertificate = toJavaCertificate(javaxCertificate);
    javaCertificatePath.add(javaCertificate);
  }

  CertificateFactory cf = CertificateFactory.getInstance("X.509");
  return cf.generateCertPath(javaCertificatePath);
}

static java.security.cert.Certificate toJavaCertificate(javax.security.cert.X509Certificate javaxCertificate) throws Exception {
  byte[] encoded = javaxCertificate.getEncoded();
  ByteArrayInputStream bis = new ByteArrayInputStream(encoded);
  java.security.cert.CertificateFactory cf = java.security.cert.CertificateFactory.getInstance("X.509");
  return cf.generateCertificate(bis);
}

Of course, we'll need to update the tests.

Having this on the 2.0.x branch would avoid us to fork the project just to add this change and it might be useful for more people using TCP.

[boaks]

it would be useful

Why?
To have "unique principal types" across DTLS/TLS?
Then we should move the org.eclipse.californium.scandium.auth to the element-connector not to create unnecessary dependencies.
Or you want to support different trust for different peers, as defined in LWM2M security object?
Is the intention therefore the TLS layer should trust everyone, and then the "application" layer will do the authorization based on the LWM2M security object. But doing so, I'm not sure, how you want to solve presenting the right client certificate to the different servers?

Though we know the requirement from LWM2M, there will be a solution (in the future), but currently I see much more urgent work in issue #429. So for now, I strongly recommend to use different endpoint to setup the right credentials and trusts for different LWM2M servers.
(Or sure, fork and go for your own, as you wrote.)

If you have a different use case, just inform us.

[AlexITC]

Yes, the elements-connector-tcp would need to depend on org.eclipse.californium.scandium.auth just to get the X509CertPath.

Ignoring dependencies, the X509CertPath contains what the X500Principal and the whole certificate chain from the client, we authenticate clients based on its own certificate in the application layer with the help of a custom Leshan Authorizer, this gives us the client identity that at the moment could be a X500Principal.

I'm not sure, how you want to solve presenting the right client certificate to the different servers?

I don't really get this.

Besides the dependency on scandium, I can't see any drawback of using the X509CertPath.

Thanks.

[boaks]

I don't really get this.

I thought, your intention was to improve the LWM2M client. If it's only the LWM2M server, then this is no issue.

So the main blocker now is the work on issue #429

[AlexITC]

Yes, this is for the server side only, I'll work in a pull request.

Thanks!

[boaks]

Do you still plan to provide a PR?

I would prefer, if the X509CertPath is then moved to the "element-connector".

[AlexITC]

yes, I would, I'm having some issues with my local tests which I need to fix before uploading the PR, I could try to move the class.