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
# openssl s_client -connectdownload.jitsi.org:443
depth=2 C = US, ST = Of Mind, L = Of Mind, O = "blah", CN = ROOTCA,
depth=1 C = US, ST = Of Mind, O = "blah", CN = MITMPROXY, emailAddress =
depth=0 OU = Domain Control Validated, CN = download.jitsi.org
0 s:/OU=Domain Control Validated/CN=download.jitsi.org
subject=/OU=Domain Control Validated/CN=download.jitsi.org
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
Protocol : TLSv1
Cipher : AES128-SHA
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/emailAddressfirstname.lastname@example.org), 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
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,
On Nov 21, 2013, at 7:34 AM, Matt Brown <email@example.com> wrote:
Sorry if that second answer was unclear. I should have written more
"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.
On Thu, Nov 21, 2013 at 7:26 AM, Matt Brown <firstname.lastname@example.org> 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
> 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,
On Thu, Nov 21, 2013 at 6:52 AM, Ingo Bauersachs <email@example.com> 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
> Is this correct? By inspecting the certificate, I can see that it is
> certificate issued by the proxy's subordinate CA. Does jitsi not check
> entire chain?
Which certificate is trusted by Windows? The subordinate CA that creates
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
it include the EKUs and SANs?
users mailing list
Unsubscribe instructions and other list options: