[jitsi-users] cacerts and SIP-TLS


#1

Hello,

I'm having trouble to connect via SSL to our SIP server over
SIP-TLS.

The server certificate is signed by a StartCom intermediate
authority. I've seen http://java.net/jira/browse/JITSI-944
that says startcom wouldn't be added to Jitsi Windows cacerts.

Fine, but then the work arounds don't seem to work.

On Windows (64bit, latest stable or nightly build), if I switch
the "Source of trusted root certificates" from "Java" to
"Windows", that works fine for XMPP, but not for SIP-TLS. I get
an error and the logs show:

14:57:13.231 SEVERE: impl.protocol.jabber.ProtocolProviderServiceJabberImpl.connectAndLogin().902 Error creating custom trust manager
java.security.KeyStoreException: problem accessing trust storejava.security.KeyStoreException: Windows-ROOT not found
        at com.sun.net.ssl.internal.ssl.TrustManagerFactoryImpl.engineInit(Unknown Source)
        at javax.net.ssl.TrustManagerFactory.init(Unknown Source)
        at net.java.sip.communicator.impl.certificate.CertificateServiceImpl.getTrustManager(CertificateServiceImpl.java:554)
        at net.java.sip.communicator.impl.certificate.CertificateServiceImpl.getTrustManager(CertificateServiceImpl.java:488)
        at net.java.sip.communicator.impl.protocol.jabber.ProtocolProviderServiceJabberImpl.connectAndLogin(ProtocolProviderServiceJabberImpl.java:888)
        at net.java.sip.communicator.impl.protocol.jabber.ProtocolProviderServiceJabberImpl.connectAndLogin(ProtocolProviderServiceJabberImpl.java:740)
        at net.java.sip.communicator.impl.protocol.jabber.ProtocolProviderServiceJabberImpl.register(ProtocolProviderServiceJabberImpl.java:397)
        at net.java.sip.communicator.impl.gui.main.login.LoginManager$RegisterProvider.run(LoginManager.java:418)
14:57:13.309 SEVERE: impl.protocol.sip.SipRegistrarConnection.register().273 Failed to create a Register request.
java.lang.IllegalArgumentException: invalid transport
        at net.java.sip.communicator.impl.protocol.sip.SipStackSharing.getJainSipProvider(SipStackSharing.java:428)
        at net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl.getJainSipProvider(ProtocolProviderServiceSipImpl.java:1659)
        at net.java.sip.communicator.impl.protocol.sip.SipRegistrarConnection.getJainSipProvider(SipRegistrarConnection.java:810)
        at net.java.sip.communicator.impl.protocol.sip.SipRegistrarConnection.register(SipRegistrarConnection.java:246)
        at net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl.register(ProtocolProviderServiceSipImpl.java:478)
        at net.java.sip.communicator.impl.gui.main.login.LoginManager$RegisterProvider.run(LoginManager.java:418)
14:57:13.528 SEVERE: service.protocol.AbstractProtocolProviderService.fireRegistrationStateChanged().155 An error occurred while executing RegistrationStateChangeLister#registrationStateChanged(RegistrationStateChangeEvent) of ProtocolProviderServiceSipImpl(stephane.chazelas@seebyte.com (SIP))
java.lang.NullPointerException
        at net.java.sip.communicator.impl.protocol.sip.SipStackSharing.stopListening(SipStackSharing.java:381)
        at net.java.sip.communicator.impl.protocol.sip.SipStackSharing.removeSipListener(SipStackSharing.java:174)
        at net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl.registrationStateChanged(ProtocolProviderServiceSipImpl.java:3236)
        at net.java.sip.communicator.service.protocol.AbstractProtocolProviderService.fireRegistrationStateChanged(AbstractProtocolProviderService.java:140)
        at net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl.fireRegistrationStateChanged(ProtocolProviderServiceSipImpl.java:419)
        at net.java.sip.communicator.impl.protocol.sip.SipRegistrarConnection.setRegistrationState(SipRegistrarConnection.java:670)
        at net.java.sip.communicator.impl.protocol.sip.SipRegistrarConnection.register(SipRegistrarConnection.java:274)
        at net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl.register(ProtocolProviderServiceSipImpl.java:478)
        at net.java.sip.communicator.impl.gui.main.login.LoginManager$RegisterProvider.run(LoginManager.java:418)
14:57:13.528 SEVERE: impl.gui.main.login.LoginManager.handleOperationFailedException().471 Provider could not be registered due to the following internal error:
net.java.sip.communicator.service.protocol.OperationFailedException: Failed to generate a from header for our register request.
        at net.java.sip.communicator.impl.protocol.sip.SipRegistrarConnection.register(SipRegistrarConnection.java:281)
        at net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl.register(ProtocolProviderServiceSipImpl.java:478)
        at net.java.sip.communicator.impl.gui.main.login.LoginManager$RegisterProvider.run(LoginManager.java:418)
Caused by: java.lang.IllegalArgumentException: invalid transport
        at net.java.sip.communicator.impl.protocol.sip.SipStackSharing.getJainSipProvider(SipStackSharing.java:428)
        at net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl.getJainSipProvider(ProtocolProviderServiceSipImpl.java:1659)
        at net.java.sip.communicator.impl.protocol.sip.SipRegistrarConnection.getJainSipProvider(SipRegistrarConnection.java:810)
        at net.java.sip.communicator.impl.protocol.sip.SipRegistrarConnection.register(SipRegistrarConnection.java:246)
        ... 2 more

(again, for XMPP, it works fine for a certificate signed exactly
the same way).

Then on Linux (debian sid amd64), I tried to import the StartCom
root CA with Java keytool (stores in ~/.keystore) or with
jcontrol (stores in ~/.java/deployment/security/trusted.cacerts)
but jitsi doesn't seem to be using any one of those (checked
with strace).

It seems the only way is to change the system keystore. On
debian, that can be done by doing a

sudo apt-get install ca-certificates-java
sudo dpkg-divert /etc/java-6-sun/security/cacerts
sudo ln -s /etc/ssl/certs/java/cacerts /etc/java-6-sun/security/cacerts

But on Windows, jitsi uses its own embeded JRE. I can import the
StartCom CA in the cacerts of that JRE (using keytool, not
provided with jitsi BTW), but it gets overriden after each
upgrade and I don't know the Windows equivalent of dpkg-divert.

Is there any way around that? Or is it possible to use the
Windows certificate store for SIP-TLS as well?

Best regards,
Stephane


#2

Hey

I'm having trouble to connect via SSL to our SIP server over SIP-TLS.

The server certificate is signed by a StartCom intermediate
authority. I've seen http://java.net/jira/browse/JITSI-944
that says startcom wouldn't be added to Jitsi Windows cacerts.

Fine, but then the work arounds don't seem to work.

On Windows (64bit, latest stable or nightly build), if I switch
the "Source of trusted root certificates" from "Java" to
"Windows", that works fine for XMPP, but not for SIP-TLS. I get
an error and the logs show:

Thanks for the report!
The problem is that the JRE 6 does not support the crypto provider to access the Windows Roots on 64 bit. The XMPP Connection only works because of a bug, and the certificate is not validated at all at this point.

-> Please don't use the Windows Root configuration option on 64bit!

We'll be removing the option to use the Windows root certs on 64 bit until we deploy the JRE 7 (hopefully soon) or find another workaround.

Regards,
Ingo


#3

2011-09-22 14:49:57 +0200, Bauersachs Ingo:
[..]

-> Please don't use the Windows Root configuration option on 64bit!

We'll be removing the option to use the Windows root certs on
64 bit until we deploy the JRE 7 (hopefully soon) or find
another workaround.

[...]

Thanks Ingo,

What about (when using "Java" as the source of certs) honouring
the certificates entered by the user via the "Java Control
Center" (on Windows, java settings in the control panel)

regards,
Stephane


#4

What about (when using "Java" as the source of certs) honouring
the certificates entered by the user via the "Java Control
Center" (on Windows, java settings in the control panel)

I'm not sure if we currently pass command-line arguments of run.exe to the JRE. If we do, you could try to set the Java property javax.net.ssl.trustStore. I have to dig a bit further how we can improve the root CA selection and the user- or system-wide set certs. The goal though is to run Jitsi on JRE7 soon, which includes the necessary libraries to access the Windows store on x64 too.

Ingo


#5

What about (when using "Java" as the source of certs) honouring
the certificates entered by the user via the "Java Control
Center" (on Windows, java settings in the control panel)

Starting with rev3678 you can set the following properties to supply a custom keystore:
net.java.sip.communicator.service.cert.truststore.type -> mapped to javax.net.ssl.trustStoreType
net.java.sip.communicator.service.cert.truststore.file -> mapped to javax.net.ssl.trustStore
net.java.sip.communicator.service.cert.truststore.password -> mapped to javax.net.ssl.trustStorePassword

The custom certs you can enter in the Java Control Panel end up in "%AppData%\..\LocalLow\Sun\Java\Deployment\security\trusted.certs". This file only contains the certs entered through the Control Panel and therefore wouldn't recognize the default certificates (given the recent scandal with DigiNotar, not a bad idea either).

The option to select the Windows TrustStore is disabled on x64 until we ship Jitsi with JRE7 and XMPP connections now fail correctly.

Thanks for bringing this up!

Regards,
Ingo


#6

2011-09-24 18:44:22 +0200, Bauersachs Ingo:

>> What about (when using "Java" as the source of certs) honouring
>> the certificates entered by the user via the "Java Control
>> Center" (on Windows, java settings in the control panel)

Starting with rev3678 you can set the following properties to supply a custom keystore:
net.java.sip.communicator.service.cert.truststore.type -> mapped to javax.net.ssl.trustStoreType
net.java.sip.communicator.service.cert.truststore.file -> mapped to javax.net.ssl.trustStore
net.java.sip.communicator.service.cert.truststore.password -> mapped to javax.net.ssl.trustStorePassword

The custom certs you can enter in the Java Control Panel end
up in
"%AppData%\..\LocalLow\Sun\Java\Deployment\security\trusted.certs".
This file only contains the certs entered through the Control
Panel and therefore wouldn't recognize the default
certificates (given the recent scandal with DigiNotar, not a
bad idea either).

[...]

Thanks Ingo,

that does work. However I cannot really use that with
provisioning so I'm trying another approach: provide the list of
trusted *server* certificates via provisioning. That works OK
except for LDAPS servers (see other thread) though that means
I'll have to update the provisioning every time our certificates
are reissued...

···

--
Stephane