@kobit the "simplest" option would be to use BouncyCastle, but I'm far from convinced it would be best one (for one - it's 4MB dependency o a very small library that tigase-utils is). Any replacement API in JDK itself is not (yet) available:

• https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8165481
• https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8058778 (We do ship bouncycasle in -dist-max via tigase-extras already though)

From what I saw, the package and required classes are still there (see sun.security.x509 on github are not normally accessible. I played a bit with the compilation configuration and managed to circumvent it:

[WARNING] /Users/wojtek/dev/tigase/tigase-utils/src/main/java/tigase/cert/OldSelfSignedCertificateGenerator.java:[20,25] sun.security.x509.AlgorithmId is internal proprietary API and may be removed in a future release
[WARNING] /Users/wojtek/dev/tigase/tigase-utils/src/main/java/tigase/cert/OldSelfSignedCertificateGenerator.java:[21,25] sun.security.x509.CertificateAlgorithmId is internal proprietary API and may be removed in a future release

But then ran into problems with other modules/packages. It seems like it would be doable (at least for now, hopefully until proper API is introduced) but it would require more tweaking (and possibly converting tigase-utils and tigase-xmltools to module system -- which we also have on our roadmap #kangaroo-62).

What do you say we should do? Try to still use internal APIs or just use BouncyCastle?

Actually, after fiddling some more with the configuration I managed to get it working. It involves profiles (so for JDK9 and onwards configuration is different) but it builds both under JDK8 and JDK9+, with the caveat that builds produced by newer JDKs won't be runnable on JDK8. But given that we still use JDK8 to build majority of the binaries (save for tigase-push) it will work just fine in overwhelming majority of cases.

In the future we can migrate do correct java.security. API when it's ready.