[jitsi-dev] wildcard certificate errors


#1

A certificate validation error popup appears when connecting to a SIP
proxy over TLS

The SIP proxy in question has a wildcard cert "*.example.org" rather
than "server.example.org"

Is this validation code in Jitsi itself, in BouncyCastle or in the Java
runtime libraries?


#2

Hi,

currently the certificate verification stuff is in CertificateService (the
impl is in net.java.sip.communicator.impl.certificate).
We build certificate chain and use the java provided TrustManager to verify
it.

Regards
damencho

···

On Wed, Jul 16, 2014 at 9:39 AM, Daniel Pocock <daniel@pocock.pro> wrote:

A certificate validation error popup appears when connecting to a SIP
proxy over TLS

The SIP proxy in question has a wildcard cert "*.example.org" rather
than "server.example.org"

Is this validation code in Jitsi itself, in BouncyCastle or in the Java
runtime libraries?

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#3

The name-comparison code is in Jitsi itself, but mostly borrowed from the browser-like validator of apache-http-client lib.
Are you sure it's because of the wildcard and not because e.g. Java doesn't trust the issuing CA? I regularly use a wildcard cert at work without problems (issued from GoDaddy).

But that reminds me again that I should improve the logging and UI of why the validation acually failed...

Freundliche Grüsse,
Ingo Bauersachs

-- sent from my mobile

···

Le 16.07.2014 à 13:41, "Daniel Pocock" <daniel@pocock.pro> a écrit :

A certificate validation error popup appears when connecting to a SIP
proxy over TLS

The SIP proxy in question has a wildcard cert "*.example.org" rather
than "server.example.org"

Is this validation code in Jitsi itself, in BouncyCastle or in the Java
runtime libraries?

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#4

Here is what I can see:

- machine is running Windows - does Jitsi use the Windows trusted roots
or the roots trusted by the JVM?

- 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.

It verifies OK with s_client, e.g.

openssl s_client -connect server.example.org:5061 -tls1 -CApath
/etc/ssl/certs

···

On 16/07/14 09:36, Ingo Bauersachs wrote:

The name-comparison code is in Jitsi itself, but mostly borrowed from the browser-like validator of apache-http-client lib.
Are you sure it's because of the wildcard and not because e.g. Java doesn't trust the issuing CA? I regularly use a wildcard cert at work without problems (issued from GoDaddy).

But that reminds me again that I should improve the logging and UI of why the validation acually failed...


#5

The name-comparison code is in Jitsi itself, but mostly borrowed from the browser-like validator of apache-http-client lib.
Are you sure it's because of the wildcard and not because e.g. Java doesn't trust the issuing CA? I regularly use a wildcard cert at work without problems (issued from GoDaddy).

But that reminds me again that I should improve the logging and UI of why the validation acually failed...

Here is what I can see:

- 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.

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 too

Is there any possible fault in the Windows root verification code?

···

On 16/07/14 10:50, Daniel Pocock wrote:

On 16/07/14 09:36, Ingo Bauersachs wrote:

- 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.

It verifies OK with s_client, e.g.

openssl s_client -connect server.example.org:5061 -tls1 -CApath
/etc/ssl/certs


#6

- 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
too

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
meanwhile.

- 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).

Ingo


#7

- 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.

That is what I would have thought. Many large organizations manage
their trust stores at the system level, e.g. adding their own in-house
root and it is good if Jitsi works seamlessly with that.

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
too

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
meanwhile.

Is there any way we can detect when this bug may be a factor and add a
warning to the popup, telling people that the cert may be OK but the JVM
needs to be upgraded?

- 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).

I had a lot of those experiences with Asterisk in the past and now I
always use repro SIP proxy as the TLS server

It then forwards things over TCP to Asterisk

repro also has a lot of server side logging about TLS errors now:

http://list.resiprocate.org/archive/resiprocate-commit/msg07921.html

···

On 16/07/14 11:14, Ingo Bauersachs wrote:


#8

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
meanwhile.

Is there any way we can detect when this bug may be a factor and add a
warning to the popup, telling people that the cert may be OK but the JVM
needs to be upgraded?

If I remember the exception correctly, then there's no way to differentiate
between a legitimately failed validation because the root CA is not trusted
by Windows and the failed background download of the CA. In the failure
case, we could possibly try to make a JNI-call to CAPI directly and trigger
the download, but I definitely don't have the time to look at this this
year.

Can you send me two logged exceptions between the failure you saw and a
really untrusted CA?

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).

I had a lot of those experiences with Asterisk in the past and now I
always use repro SIP proxy as the TLS server

It then forwards things over TCP to Asterisk

repro also has a lot of server side logging about TLS errors now:

http://list.resiprocate.org/archive/resiprocate-commit/msg07921.html

Thanks for this hint. For our small setup, Asterisk works just enough to
avoid further complications with the rather limit knowledge around SIP and
Linux in general.

Ingo

···

On 2014-07-16 16:58, Daniel Pocock wrote:

On 16/07/14 11:14, Ingo Bauersachs wrote: