[jitsi-users] X.509 certificates: Subject Alternative Names ignored


#1

Jitsi does check the SAN. Can you take a look at the logs
(https://jitsi.org/logs) to see why validation fails exactly?

I got the log file from Marcel privately:
"unable to find valid certification path to requested target"

So, Marcel, the certificate used by your server couldn't be validated to a trusted CA. If it is self-signed or from your company, then this is normal. You have to accept the warning or select the checkbox that you always want to trust it.
If it is from an well-known CA, then your server might be incorrectly configured and doesn't send all intermediate certificates. Otherwise the CA is not well-known enough for Java 1.8.40.

The protocol part of the srv is left out because of an rfc that says so.
Don't know which one out of my head.

Dane will be coming sometime this year (hopefully I'll find the time).

Freundliche Grüsse,
Ingo Bauersachs

Ingo


#2

Ingo, all,

the certificate information seems to be OK according to XMPP.net [1]. Jitsi on Linux (Ubuntu) is able to connect without problems to my server. So SAN seem to be interpreted correctly. However, on the Mac, Jitsi still complains.

The only potential difference I came up with, were the root CA store, but according to "keytool -list -v -keystore /Library/Java/Home/lib/security/cacerts -storepass changeit“ and the Java System Preferences settings, the root (StartCom) is available.

[1] https://xmpp.net/result.php?domain=wanda.ch&type=client

···

Am 23.04.2015 um 18:03 schrieb Ingo Bauersachs <ingo@jitsi.org>:

Jitsi does check the SAN. Can you take a look at the logs
(https://jitsi.org/logs) to see why validation fails exactly?

I got the log file from Marcel privately:
"unable to find valid certification path to requested target"

So, Marcel, the certificate used by your server couldn't be validated to a trusted CA. If it is self-signed or from your company, then this is normal. You have to accept the warning or select the checkbox that you always want to trust it.
If it is from an well-known CA, then your server might be incorrectly configured and doesn't send all intermediate certificates. Otherwise the CA is not well-known enough for Java 1.8.40.

The protocol part of the srv is left out because of an rfc that says so.
Don't know which one out of my head.

Dane will be coming sometime this year (hopefully I'll find the time).

Freundliche Grüsse,
Ingo Bauersachs

Ingo

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


#3

We use an embedded JRE for Jitsi on Mac (and Windows), so the path you supplied to the keytool to check is incorrect. I dont't use Macs normally so I can't tell the correct path currently, but it should be irrelevant as I think StartCom is part of th normal JRE and we of course don't modify the truststore.

So currently I'm out of ideas. Can some other dev please try to connect to wanda.ch and see why it fails?

Freundliche Grüsse,
Ingo Bauersachs

-- sent from my mobile

···

On 29.04.2015, at 14:38, Marcel Waldvogel <Marcel.Waldvogel@uni-konstanz.de> wrote:

Ingo, all,

the certificate information seems to be OK according to XMPP.net [1]. Jitsi on Linux (Ubuntu) is able to connect without problems to my server. So SAN seem to be interpreted correctly. However, on the Mac, Jitsi still complains.

The only potential difference I came up with, were the root CA store, but according to "keytool -list -v -keystore /Library/Java/Home/lib/security/cacerts -storepass changeit“ and the Java System Preferences settings, the root (StartCom) is available.

[1] https://xmpp.net/result.php?domain=wanda.ch&type=client

Am 23.04.2015 um 18:03 schrieb Ingo Bauersachs <ingo@jitsi.org>:

Jitsi does check the SAN. Can you take a look at the logs
(https://jitsi.org/logs) to see why validation fails exactly?

I got the log file from Marcel privately:
"unable to find valid certification path to requested target"

So, Marcel, the certificate used by your server couldn't be validated to a trusted CA. If it is self-signed or from your company, then this is normal. You have to accept the warning or select the checkbox that you always want to trust it.
If it is from an well-known CA, then your server might be incorrectly configured and doesn't send all intermediate certificates. Otherwise the CA is not well-known enough for Java 1.8.40.

The protocol part of the srv is left out because of an rfc that says so.
Don't know which one out of my head.

Dane will be coming sometime this year (hopefully I'll find the time).

Freundliche Grüsse,
Ingo Bauersachs

Ingo

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

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