Migration to Californium 2.3.0

[boaks]

I was wondering, why a new project uses 2.0.0-M13 (more than a year old) and so I tried to update to Californium 2.3.0.

My results:

• the CoapClient get/post/... uses checked exceptions since 2.0.0. In M13 the exceptions are forwarded as unchecked ones. I think, it should be easy to either catch or wrap these IOException and ConnectorException.
• the DtlsConfigurationBuilder reports, that it is invalid to apply a CertificateVerifier after the trusted certificates are applied. With the growing dtls configuration the implementation was changed to try to validate the provided configuration. Using "trusted certificates" would use the default CertificateVerifier in order to migrate from much earlier version (before the introduction of the CertificateVerifier). It just doesn't work, to use both, set "trusted certificates" and a custom CertificateVerifier.

    if (verifier != null) {
      config.setCertificateVerifier(verifier);
    } else {
      config.setTrustStore(trustAnchors);
    }

may do the trick.

• misusage of CertificateVerifier.
  Implementations as PledgeCertificateVerifier has always been a "no go".

 public CertPath getPeerCertPath() {
    return peerCertPath;
  } 

That relies on exactly one request at one time! To read the CertPath of the other peer in a safe way even with multiple request is very easy:
-- Client side: read the source endpoint context of the received response.
-- Server side: read the source endpoint context of the received request.
In both case, the peer identity in that context will contain a X509CertPath (if x509 is used for authentication). In my opinion, that is much more straight forward.

My impression is, that this may also eliminate the use of custom verifier. If you just want to trust all "valid certificate path" not based on trust anchors, it's easier to use DtlsConfigBuilder.setTrustStore(new Certificate[0]). That will validate the certificate chain without limiting the trust anchor to a specific set.

• used "trusted certificates" seems not to match the provided certificate path.
  If I execute the unit test with Californium 2.1.0 or newer, they fail and the logs shows, that a clients certificate is missing for the second handshake. Investigating shows, that the server sends a issuer list (derived from the servers trusted certificates), but the client has no certificate path, which contains one of these issuers. Therefore the client send a empty certificate. There are several options to fix that:
  -- if the server should trust all trust anchors, provide a empty certificate array (see comment above about the custom certificate verifier).
  -- if the server should trust based on specific trust anchors, provide the right ones, which are also used to sign he client's certificate.
  -- as "dirty work around", the client may also just be configured using
  DtlsConfigBuilder.setUseTruncatedCertificatePathForClientsCertificateMessage(false);