[jitsi-users] keystore location for client auth by cert on Windows

Archive
1

Hello,

I am interested in finding out the location of the JKS that the jitsi
client refers to by default, and also how to configure this.

I have read that on linux the location is ~/.jitsi.keytool but when I
use %homedrive%%homepath%\.jitsi.keytool certs are not found. I have
also imported the signed cert into the Windows cert store without
luck.

Additionally I used process monitor to track file reads and was unable
to locate the JKS file used.

I attempted to search the mailing list and came up with nothing.

This will help me migrate from Skype and is a great feature.

Any assistance is appreciated.

Thanks,

Matt

2

Hi

I am interested in finding out the location of the JKS that the jitsi
client refers to by default, and also how to configure this.

I have read that on linux the location is ~/.jitsi.keytool but when I
use %homedrive%%homepath%\.jitsi.keytool certs are not found. I have
also imported the signed cert into the Windows cert store without luck.

Where did you get that from?

Additionally I used process monitor to track file reads and was unable
to locate the JKS file used.

I attempted to search the mailing list and came up with nothing.

This will help me migrate from Skype and is a great feature.

Any assistance is appreciated.

Client auth is only possible for SIP and XMPP accounts. You first need to
configure a client certificate template in Tools -> Options -> TLS
configuration. There you can choose to use a Keystore-File (.ks, .jks), a
PKCS#12-Container (.pfx) or a PKCS#11 library (.so, .dll, .dynalib) for
smartcards.
Afterwards you select this template for your SIP or XMPP account.

Here's a tutorial for a SIP account against reSIProcate:
http://www.resiprocate.org/ReproMutualTLSAuthenticationJitsi

Please note that this feature is not widely used and might very well contain
bugs.

Thanks,
Matt

Ingo

3

Thanks Ingo.

I have the source set to Windows for trusted root certificate (as is the
default), which leads me to believe this is non-functional, as I have a
MiTM proxy for inspection of TLS traffic, but am still warned when
connecting to the server and checking for updates. I believe this is a
separate problem (?).

I will work on this further tomorrow and beyond the above issues, hopefully
all will work well.

Thanks,

Matt

Matt Brown

···

On Wed, Nov 20, 2013 at 5:07 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

Hi

> I am interested in finding out the location of the JKS that the jitsi
> client refers to by default, and also how to configure this.
>
> I have read that on linux the location is ~/.jitsi.keytool but when I
> use %homedrive%%homepath%\.jitsi.keytool certs are not found. I have
> also imported the signed cert into the Windows cert store without luck.

Where did you get that from?

> Additionally I used process monitor to track file reads and was unable
> to locate the JKS file used.
>
> I attempted to search the mailing list and came up with nothing.
>
> This will help me migrate from Skype and is a great feature.
>
> Any assistance is appreciated.

Client auth is only possible for SIP and XMPP accounts. You first need to
configure a client certificate template in Tools -> Options -> TLS
configuration. There you can choose to use a Keystore-File (.ks, .jks), a
PKCS#12-Container (.pfx) or a PKCS#11 library (.so, .dll, .dynalib) for
smartcards.
Afterwards you select this template for your SIP or XMPP account.

Here's a tutorial for a SIP account against reSIProcate:
http://www.resiprocate.org/ReproMutualTLSAuthenticationJitsi

Please note that this feature is not widely used and might very well
contain
bugs.

> Thanks,
> Matt

Ingo

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

4

I have the source set to Windows for trusted root certificate (as is the
default), which leads me to believe this is non-functional, as I have a
MiTM proxy for inspection of TLS traffic, but am still warned when
connecting to the server and checking for updates. I believe this is a
separate problem (?).

What certificate does the proxy present to the clients? Is it generated on
the fly for the target domain-name? Just having a random certificate trusted
by the OS won't work.

I will work on this further tomorrow and beyond the above issues,

hopefully

all will work well.

Thanks,
Matt

Ingo

5

Yes, the proxy houses a subordinate CA that generates certs on-the-fly. It
works without issue in browsers (I've also added the cert to the Firefox
cert store).

I figured that Jitsi referred to a JKS and not the Windows store, but
registry access tells me that Jitsi does actually access the Windows
store. Is this correct? By inspecting the certificate, I can see that it
is the certificate issued by the proxy's subordinate CA. Does jitsi not
check the entire chain?

Thanks,

Matt

Matt Brown

···

On Thu, Nov 21, 2013 at 2:01 AM, Ingo Bauersachs <ingo@jitsi.org> wrote:

> I have the source set to Windows for trusted root certificate (as is the
> default), which leads me to believe this is non-functional, as I have a
> MiTM proxy for inspection of TLS traffic, but am still warned when
> connecting to the server and checking for updates. I believe this is a
> separate problem (?).

What certificate does the proxy present to the clients? Is it generated on
the fly for the target domain-name? Just having a random certificate
trusted
by the OS won't work.

> I will work on this further tomorrow and beyond the above issues,
hopefully
> all will work well.
>
>
> Thanks,
> Matt

Ingo

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

6

Yes, the proxy houses a subordinate CA that generates certs on-the-fly.
It works without issue in browsers (I've also added the cert to the
Firefox cert store).

I figured that Jitsi referred to a JKS and not the Windows store, but
registry access tells me that Jitsi does actually access the Windows

store.

Is this correct? By inspecting the certificate, I can see that it is the
certificate issued by the proxy's subordinate CA. Does jitsi not check

the

entire chain?

Which certificate is trusted by Windows? The subordinate CA that creates the
on-the-fly certs or the root CA? If it is the root CA, you must make sure
that either the proxy delivers the complete chain of the certificates with
the exception of the root CA (and not just the on-the-fly certificate
itself) OR the AIA information in the on-the-fly certificate and the
subordinate CA cert must point to a HTTP location where Jitsi can download
the intermediate certificates.

How are these certs generated? Is the proxy just copying the Subject or does
it include the EKUs and SANs?

Thanks,
Matt

Ingo

7

Thanks for the fast reply Ingo:

Which certificate is trusted by Windows? The subordinate CA that creates

the on-the-fly certs or the root CA?
The root CA cert is trusted by Windows. The subordinate CA generates the
certs on-the-fly. When inspecting the certificate (via the Windows cert
management), the entire chain is present and trusted. I also have imported
the root CA cert into the store that Firefox uses, and there is no problem
with the certs that the subordinate CA issues.

If it is the root CA, you must make sure that either the proxy delivers

the complete chain of the certificates with the exception of the root CA
(and not just the on-the-fly certificate itself) OR the AIA information in
the on-the-fly certificate and the subordinate CA cert must point to a HTTP
location where Jitsi can download the intermediate certificates.
It is the subordinate CA that is trusted. I will verify that all the certs
in the cert chain are delivered using the `openssl` client today; but if
jitsi is referring to the Windows cert store for trust (and it is referring
somewhere for trust, because I do not have this trust problem outside of
the proxy MiTMing), then is it right that the root CA cert (that already
lives in the Windows store) is not necessary to be delivered on-the-fly?

How are these certs generated? Is the proxy just copying the Subject or

does it include the EKUs and SANs?
I will have to look into this further and will get back to you.

Thanks again for your fast replies,

Matt

Matt Brown

···

On Thu, Nov 21, 2013 at 6:52 AM, Ingo Bauersachs <ingo@jitsi.org> wrote:

> Yes, the proxy houses a subordinate CA that generates certs on-the-fly.
> It works without issue in browsers (I've also added the cert to the
> Firefox cert store).
>
>
> I figured that Jitsi referred to a JKS and not the Windows store, but
> registry access tells me that Jitsi does actually access the Windows
store.
> Is this correct? By inspecting the certificate, I can see that it is the
> certificate issued by the proxy's subordinate CA. Does jitsi not check
the
> entire chain?

Which certificate is trusted by Windows? The subordinate CA that creates
the
on-the-fly certs or the root CA? If it is the root CA, you must make sure
that either the proxy delivers the complete chain of the certificates with
the exception of the root CA (and not just the on-the-fly certificate
itself) OR the AIA information in the on-the-fly certificate and the
subordinate CA cert must point to a HTTP location where Jitsi can download
the intermediate certificates.

How are these certs generated? Is the proxy just copying the Subject or
does
it include the EKUs and SANs?

> Thanks,
> Matt

Ingo

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

8

Sorry if that second answer was unclear. I should have written more
clearly:

"It is the subordinate CA that is trusted [because the chain is trusted (as
the root CA is trusted by the Windows certificate store)]."

Dominantly, it is an important note that this is the first issue I have
come across with this proxy. If a client app respects the Windows cert
store, then there have been no issues.

Thanks,

Matt

Matt Brown

···

On Thu, Nov 21, 2013 at 7:26 AM, Matt Brown <matthewbrown@gmail.com> wrote:

Thanks for the fast reply Ingo:

> Which certificate is trusted by Windows? The subordinate CA that creates
the on-the-fly certs or the root CA?
The root CA cert is trusted by Windows. The subordinate CA generates the
certs on-the-fly. When inspecting the certificate (via the Windows cert
management), the entire chain is present and trusted. I also have imported
the root CA cert into the store that Firefox uses, and there is no problem
with the certs that the subordinate CA issues.

> If it is the root CA, you must make sure that either the proxy delivers
the complete chain of the certificates with the exception of the root CA
(and not just the on-the-fly certificate itself) OR the AIA information in
the on-the-fly certificate and the subordinate CA cert must point to a HTTP
location where Jitsi can download the intermediate certificates.
It is the subordinate CA that is trusted. I will verify that all the
certs in the cert chain are delivered using the `openssl` client today; but
if jitsi is referring to the Windows cert store for trust (and it is
referring somewhere for trust, because I do not have this trust problem
outside of the proxy MiTMing), then is it right that the root CA cert (that
already lives in the Windows store) is not necessary to be delivered
on-the-fly?

> How are these certs generated? Is the proxy just copying the Subject or
does it include the EKUs and SANs?
I will have to look into this further and will get back to you.

Thanks again for your fast replies,

Matt

Matt Brown

On Thu, Nov 21, 2013 at 6:52 AM, Ingo Bauersachs <ingo@jitsi.org> wrote:

> Yes, the proxy houses a subordinate CA that generates certs on-the-fly.
> It works without issue in browsers (I've also added the cert to the
> Firefox cert store).
>
>
> I figured that Jitsi referred to a JKS and not the Windows store, but
> registry access tells me that Jitsi does actually access the Windows
store.
> Is this correct? By inspecting the certificate, I can see that it is
the
> certificate issued by the proxy's subordinate CA. Does jitsi not check
the
> entire chain?

Which certificate is trusted by Windows? The subordinate CA that creates
the
on-the-fly certs or the root CA? If it is the root CA, you must make sure
that either the proxy delivers the complete chain of the certificates with
the exception of the root CA (and not just the on-the-fly certificate
itself) OR the AIA information in the on-the-fly certificate and the
subordinate CA cert must point to a HTTP location where Jitsi can download
the intermediate certificates.

How are these certs generated? Is the proxy just copying the Subject or
does
it include the EKUs and SANs?

> Thanks,
> Matt

Ingo

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

9

Hello Igno,

The following cert is only the generated and issued cert, it doesn't
contain the full chain (the Root CA cert and the subordinate is not
present).

# openssl s_client -connectdownload.jitsi.org:443
CONNECTED(00000003)
depth=2 C = US, ST = Of Mind, L = Of Mind, O = "blah", CN = ROOTCA,
emailAddress =mbrown@adomain.com
verify return:1
depth=1 C = US, ST = Of Mind, O = "blah", CN = MITMPROXY, emailAddress =
mbrown@adomain.com
verify return:1
depth=0 OU = Domain Control Validated, CN = download.jitsi.org
verify return:1

···

---
Certificate chain
0 s:/OU=Domain Control Validated/CN=download.jitsi.org
  i:/C=US/ST=OfMind/O=blah/CN=MITMPROXY/emailAddress=mbrown@adomain.com
1 s:/C=US/ST=OfMind/O=blah/CN=MITMPROXY/emailAddress=mbrown@adomain.com
  i:/C=US/ST=Of Mind/L=Of
Mind/O=blah/CN=ROOTCA/emailAddress=mbrown@adomain.com
---
Server certificate
-----BEGIN CERTIFICATE-----
[BLOB]
-----END CERTIFICATE-----
subject=/OU=Domain Control Validated/CN=download.jitsi.org
issuer=/C=US/ST=OfMind/O=blah/CN=MITMPROXY/emailAddress=mbrown@adomain.com
---
No client certificate CA names sent
---
SSL handshake has read 1231 bytes and written 103 bytes
---
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 1024 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
   Protocol : TLSv1
   Cipher : AES128-SHA
   Session-ID: [BLOB]
   Session-ID-ctx:
   Master-Key: [BLOB]
   Key-Arg : None
   Krb5 Principal: None
   PSK identity: None
   PSK identity hint: None
   Start Time: 1385050870
   Timeout : 300 (sec)
   Verify return code: 0 (ok)
---

This is odd, as the Windows trust store contains the Root CA (/C=US/ST=Of
Mind/L=OfMind/O=blah/CN=ROOTCA/emailAddress=mbrown@adomain.com), and since
the chain is trusted this cert should be.

Which cert store is jitsi reading?

re: EKU and SAN...

Extended Key Usage: As explained here (
http://security.stackexchange.com/a/30944), I do not see the need... but...

Subject Alternative Name: which is an EKU, is included in the certificate
as:
DNS Name=download.jitsi.org
DNS Name=www.download.jitsi.org
DNS Name=trac.jitsi.org

I hope this verifies that the MiTM proxy function is working as expected
and acceptably for the Jitsi client.

Is it true that jitsi is looking at the Windows cert store?

Thanks very much,

Matt

On Nov 21, 2013, at 7:34 AM, Matt Brown <matthewbrown@gmail.com> wrote:

Sorry if that second answer was unclear. I should have written more
clearly:

"It is the subordinate CA that is trusted [because the chain is trusted (as
the root CA is trusted by the Windows certificate store)]."

Dominantly, it is an important note that this is the first issue I have
come across with this proxy. If a client app respects the Windows cert
store, then there have been no issues.

Thanks,

Matt

Matt Brown

On Thu, Nov 21, 2013 at 7:26 AM, Matt Brown <matthewbrown@gmail.com> wrote:

Thanks for the fast reply Ingo:

> Which certificate is trusted by Windows? The subordinate CA that creates
the on-the-fly certs or the root CA?
The root CA cert is trusted by Windows. The subordinate CA generates the
certs on-the-fly. When inspecting the certificate (via the Windows cert
management), the entire chain is present and trusted. I also have imported
the root CA cert into the store that Firefox uses, and there is no problem
with the certs that the subordinate CA issues.

> If it is the root CA, you must make sure that either the proxy delivers
the complete chain of the certificates with the exception of the root CA
(and not just the on-the-fly certificate itself) OR the AIA information in
the on-the-fly certificate and the subordinate CA cert must point to a HTTP
location where Jitsi can download the intermediate certificates.
It is the subordinate CA that is trusted. I will verify that all the
certs in the cert chain are delivered using the `openssl` client today; but
if jitsi is referring to the Windows cert store for trust (and it is
referring somewhere for trust, because I do not have this trust problem
outside of the proxy MiTMing), then is it right that the root CA cert (that
already lives in the Windows store) is not necessary to be delivered
on-the-fly?

> How are these certs generated? Is the proxy just copying the Subject or
does it include the EKUs and SANs?
I will have to look into this further and will get back to you.

Thanks again for your fast replies,

Matt

Matt Brown

On Thu, Nov 21, 2013 at 6:52 AM, Ingo Bauersachs <ingo@jitsi.org> wrote:

> Yes, the proxy houses a subordinate CA that generates certs on-the-fly.
> It works without issue in browsers (I've also added the cert to the
> Firefox cert store).
>
>
> I figured that Jitsi referred to a JKS and not the Windows store, but
> registry access tells me that Jitsi does actually access the Windows
store.
> Is this correct? By inspecting the certificate, I can see that it is
the
> certificate issued by the proxy's subordinate CA. Does jitsi not check
the
> entire chain?

Which certificate is trusted by Windows? The subordinate CA that creates
the
on-the-fly certs or the root CA? If it is the root CA, you must make sure
that either the proxy delivers the complete chain of the certificates with
the exception of the root CA (and not just the on-the-fly certificate
itself) OR the AIA information in the on-the-fly certificate and the
subordinate CA cert must point to a HTTP location where Jitsi can download
the intermediate certificates.

How are these certs generated? Is the proxy just copying the Subject or
does
it include the EKUs and SANs?

> Thanks,
> Matt

Ingo

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

10

The following cert is only the generated and issued cert, it doesn't

contain

the full chain (the Root CA cert and the subordinate is not present).

# openssl s_client -connect download.jitsi.org
[...]

This is odd, as the Windows trust store contains the Root CA (/C=US/ST=Of
Mind/L=OfMind/O=blah/CN=ROOTCA/emailAddress=mbrown@adomain.com), and since
the chain is trusted this cert should be.

This looks correct.
What server are you connecting to? And is the server-part of your username
matching the certificate?
E.g. for an XMPP-username alice@example.com, the certificate must be issued
to example.com or _xmpp-client.example.com, for SIP either to example.com or
the manually entered SIP proxy name.

Which cert store is jitsi reading?

If you select Windows as the root CA source, then the Java system property
javax.net.ssl.trustStoreType is set to "Windows-ROOT".

re: EKU and SAN...

Extended Key Usage: As explained here
(http://security.stackexchange.com/a/30944), I do not see the need...

but...

Subject Alternative Name: which is an EKU, is included in the certificate

as:

DNS Name=download.jitsi.org <http://download.jitsi.org/>
DNS Name=www.download.jitsi.org <http://www.download.jitsi.org/>
DNS Name=trac.jitsi.org <http://trac.jitsi.org/>

I hope this verifies that the MiTM proxy function is working as expected

and

acceptably for the Jitsi client.

Is it true that jitsi is looking at the Windows cert store?

As long as it is selected this way in the options dialog, yes.

Thanks very much,
Matt

Ingo