Skip navigation
All People > Alameyo > Alameyo's GSoC 2017 Blog > 2017 > July

Hi there ,


This week I was implementing Online Certificate Status Protocol. Java allow to implement it in form of PKIXRevocationChecker which is added to the parameters of certificate path which is later validated. PKIXRevocationChecker is abstract class so it need some work on implementation and it is Openfire's way to handle this problem (well, it also use more abstract PKIXCertPathChecker class). Before I come to the my solution for PKIXRevocationChecker let's try to grasp some knowledge about what is OCSP?


It's protocol defined in rfc6960 for checking certificate revocation. In many ways it is superior to the CRLs as it doesn't require downloading whole lists for certificates which we aren't processing. However is not included in the basic PKI document while CRL way of checking of revocation is. Why? I can only guess but it is maybe bit more complicated and requires constantly working server, while in theory CRL's can be cached for group certificates and used for some period of time. Anyway OCSP isn't so popular as CRLs so any implementation of it should support CRL as backup.

OCSP include two parts: client request and server response.


An OCSP request contains:

   - protocol version

   - service request

   - target certificate identifier

   - optional extensions

Basic response include:

  - version of the response syntax

  - identifier of the responder

  - time when the response was generated

  - responses for each of the certificates in a request  - that means by one request response we can check group of certificates. Response can be good, revoked or unknown.

  - optional extensions

  - signature algorithm OID

  - signature computed across a hash of the response

Protocol states that there can be many types of response but at least that one basic have to be supported in every server side implementation of OCSP.


Now back to Java implementation of OCSP. While creating own checker is completely fine I found out that according to the Java PKI Programmer's Guide I can use CertPathBuilder to get instance of OCSP checker ( which also checks as backup CRLs ). Then I can change some of the options in this checker and add it to the parameters used in certificate chain validation. That's all. Why Openfire doesn't use it? The reason might be that this PKIXRevocationChecker was introduced in Java 8, while Openfire is much older software. So Openfire's way is perfectly cool, just person who did it couldn't use Java 8 then, which simplify it now.


See you next week,


Hi there,


This week I was continuing working on the trust managers, and I added support for Certificate Revocation List. Certificate extension with OID contain link to the server with CRL file. Spark Trust Manager before SSL connection downloads all CRL list from web, create additional CertStore, save this CRLs to that store and through PKIX parameters use it for checking certificates revocation.


What's wrong with that method? Sometimes CRL lists can grow really huge, easy over 1000 entries so sometimes it can be over few MB of data. That can be sometimes overkill for some networks (someone still use dial up? ) and just parsing through it can takes some time. Anyway there is other way of checking if certificate is revoked which is Online Certificate Status Protocol. It allow to just send to server request for status of just one certificate so this save bandwidth and time. The only problem with that is it is less common extension for certificates, so if one doesn't have it Trust Manager still have to support CRLs.


The fun thing I noticed is that often people asking for help on the Ignite Realtime forum and open chat have problem with establishing connection with Smack and they are happy when it starts work for them. In meantime I was few times happy when I couldn't establish connection, because that means that SSL is working as there were no adequate certificate in TrustStore or it was invalid.


See you next week,



#9 Trust managers.

Posted by Alameyo Jul 14, 2017



This week I started working on vanilla purpose of certificates which is authentication of the public key issuers. From Smack point of view I have to create SSLContext which is going to be processed further in Smack. This context require me to provide Trust Managers which task is to provide context with accepted issuers and validate certificates. Writing Trust Managers well is difficult job and it is easy to make mistakes that would result in accepting certificates which shouldn't be accepted.


What makes it especially hard is that I create trust manager that will sometimes accept certificates that shouldn't be accepted . It will be left for Spark user if he want to accept expired certificate or even revoked and by that consciously lost some of the security guarantees from validation mechanisms.


Is that wrong? Yes.

Should it be done? Definitely no.


Still even web browsers allow user to add certificate to exception list . My task is to allow Spark's users to do the same and even provide greater flexibility at setting which parts of validation bypass. I created 2 Trust Managers. First serve as default Trust Manager which is provided in SSLContext initialization. Second one is Exceptions Trust Manager which is called internally in default Trust Manager. It contain as accepted issuers only list of exempted certificates but doesn't do any checks on validity of it. If it fails (which will only happen when presented by server chain of certificates doesn't contain one of the exempted certificates) then authentication logic goes back to default trust manager which make use of all trusted issuers certificates and do every required check, unless user disable particular "validity test" in certificates interface.


See you next week,



#8 Exceptions list and SSL

Posted by Alameyo Jul 7, 2017



This week I was doing mainly research into SSL/TLS, how to use it with Smack and how it is used with Spark. Generally speaking Smack's connection configuration have method setSSLContext(SSLContext context) where I can specify SSL options. What is SSL? That's SecureSocetsLayer Protocol which is in charge of maintaining secure connection between two parties (server and client). The most important part of this protocol is keys exchange which might be RSA public keys or symmetric secret keys using Diffie-Hellman exchange. Smack allow me to not dig too deep into that but I still must specify some things with this context. One of this things is providing list of trusted certificates (certificates also contain public Keys). Next week I plan to do some more work on this .


Apart from that I added 3 Keystores for Spark: one for exempted certificates, second for trusted/valid and third one for revoked. Now after clicking on checkbox certificates are added to exceptions list. That means PKI tab in login settings probably will disappear from Spark so it will be using only it's own Keystores, also due to some weird settings in SSL configuration it wasn't working as supposed . Also during working on method that moves certificates between Keystores one thing surprised me. It is impossible to load Keystore file that is empty in this case I had to pass "null" as argument for Keystore load method. Not big deal but if I wouldn't found out it, that could later cause some unpleasant consequences.