I just committed a change that allows you to configure the CRL and OCSP
checking in the TLS configuration advanced options panel. They are currently
not enabled by default, but we (the other devs) can discuss to enable the
As I consider the OCSP-Implementation of Java to be broken, enabling that by
default is currently not an option. Broken means that it causes validation
failures on perfectly valid certificates. About the sense of OCSP in
general, you might want to read this  blog post. I know it's a bit dated,
but the problems still apply.
Thanks for noting that those stuff is not enabled by default!
From: Buddy Butterfly [mailto:email@example.com]
Sent: Mittwoch, 5. Dezember 2012 10:15
Subject: [jitsi-dev] Re: TLS Client Certificate Support for XMPP
ok, JCA also supports the CRL distribution points but they are also
disabled by default:
--- snip ---
Support for the CRL Distribution Points Extension
Support for the CRL Distribution Points extension is available. It is
disabled by default for compatibility and can be enabled by setting the
system property com.sun.security.enableCRLDP to the value true.
If set to true, Sun's PKIX implementation uses the information in a
certificate's CRL Distribution Points extension (in addition to CertStores
that are specified) to find the CRL, provided the distribution point is an
X.500 distinguished name or a URI of type ldap, http, or ftp.
--- snap ---
So both, CRL distribution point and OCSP are disabled by default.
ok, here you got me. Did not look into the code, just wanted to
point out its importance. So
1. JCA has "ocsp.enable" false by default.
2. Properties like "ocsp.enable" can be set dynamically via
java.security.Security.setProperty(). I did not find any option
that on the GUI.
So, a quick look at documentation showed that there is support for
in JCA, it just should be configurable. CRL handling on the other
is not very clear and would need some testing to reveal. Though,
Appendix B: The "SUN" provider states: " It does not implement
for the freshest CRL or ..." which I understand as implementing a CRL
verification against the CRL cache but no online retrieval by
From this it looks like OCSP would be nice to enable. It can also be
done Java wide in the security options.
thanks for reply. Sry, but it was too early today
I overlooked the "TLS Client" ;-). I immediately
with a reply to my own mail.
I saw your second mail, but replied anyway because of the
As long as I know there is probably support for CRL
but it will not happen automatically. Unfortunately
the whole PKI
is mostly driven by organizational / manual decisions.
Sorry, I don't get what you mean. Could you elaborate that a
So to have at least a base minimum on security, the
check for the
validity of the certificate is necessary. And, if I
right, the CRL (Certificate Revocation List)
are even optional in X509. And in general nowadays
we talk about the
OCSP (Online Certificate Status Protocol) which is
Jitsi uses the TLS infrastructure of the Java Cryptography
API and as
such checks validity, CA certificates, CRLs, the CA-chain flags,
necessary certificate usage flags and as far as I know also
In addition to Java's certificate check, we validate the
against the hostname (which is what most applications using
In Firefox you can find the example in
There it is specified to validate the certificate if
OCSP-Server or a manually configured one can be
We don't have an option to explicitly enable or disable
OCSP, but you
can try to override settings manually with Java's ocsp.XYZ
Have you noticed that something is not working as expected?
good idea. Just a reminder. In terms
CRL service (configurable) and
The client certificate that Stefan wants to
implement needs to be
checked on the server side.
CRL: TLS client has to read
distribution points in server
cetificates and contact the
points to see if certificate is
still valid or has been revoked. If
provided in certificate manual
configuration of distribution points
be desirable. This implies
technical connectivity to different
like http, ldap (directory
We rely on the Java cryptography
do that. If you find
errors in our usage of the API however, I'd
happy to fix them.
Client has private key and client
certificate which then in turn is
server to authenticate. This is like
common browsers where you
import a .p12
containing private key and
authenticate to a secure side.
That's exactly what we're talking about, and
already there for SIP.
When it must be prioritized, CRL has
more priority as one has to
server certificate is still valid or
been compromised. We all have
heard of the
crappy safety of CA authorities out
Am 05.12.2012 16:09, schrieb Buddy Butterfly:
Am 05.12.2012 15:38, schrieb Ingo Bauersachs:
Am 05.12.2012 15:10, schrieb Ingo Bauersachs:
so the more important this