- machine is running Windows - does Jitsi use the Windows trusted
roots or the roots trusted by the JVM?
I found the answer to this point in the TLS settings: it was using the
Windows trust store.
That is the default and recommended. The Java truststore is usually
outdated, especially if one uses a release build of Jitsi which might not
ship with the newest JRE release.
I changed it to use the Java trust store that makes the error go
away - but the root certificate does exist in the Windows trust store
Is there any possible fault in the Windows root verification code?
Yes, it's a bug in Java. If the root certificate hasn't been used in
Internet Explorer, Chrome or any other application that uses Windows' CAPI
correctly, then the validation in Java will fail. I can't remember the
Oracle bug entry, but even then I highly suspect it has been fixed
- it is signed by:
intermiediate: "DigiCert High Assurance CA-3"
root: "DigiCert High Assurance EV Root CA"
- wildcard in the Common Name field: *.example.org
- expiry in 2016
- 2048 bit and SHA1 (if it was 1024 or MD5 then it would be OK to
reject it, but 2048/SHA1 should be accepted?)
At one point, the intermediate certificate was missing from the PEM
file on the SIP proxy. I added the intermediate cert though and the
same error is still appearing.
If you use Asterisk as the server, make sure your patch to send the
intermediates is applied (if it's not the newest 11 release).