2

Let assume that I have a Linux based server running apache or tomcat with a web server certificate created by a trusted authority. The certificate has embedded distribution point of the crl. The question is as follows: Whenever my server communicates via ssl with another entity(server, user, etc) , does it relying on a valid crl or trust chain is enough? (default configuration)

Edit: The situation is that my organization consist of windows environment and Linux environment. The organization utilize Microsoft CA for certificates of servers and client which both Windows and Linux use. There is a public server hosting the crl files. Most of the Linux environment consist apache servers and db servers, communicating via ssl.

The question is what would happen to the Linux environment if the crl server would gone offline. Would the Linux server able to communicate by verify the chain trust or would it fail to verify without crl available. The question is kind of abstract because I have many kinds of servers in that environment, however I'd like to know the general situation in such scenario.

Second Edit: I'd like to mention that in our Linux environment, we use OpenSSL for creating the CSR's and installing the certificates.

  • 1
    If I'm not mistaken, CRLs are verified on client side (e.g. by the browsers), why would a server bother to do it? – Dmitry Grigoryev Mar 18 '16 at 10:08
  • @DmitryGrigoryev In Windows environment as much as I know, CRLs are verified with any ssl communication. Whether it is between a client to a computer, browser and a website, server and server (example : application and database). I'd like to know if it is the same in Linux environment. – user161736 Mar 18 '16 at 10:19
  • You don't seem to understand my point. CRLs are verified by clients and apache is the server. Or does it act as a client in your setup somehow? – Dmitry Grigoryev Mar 18 '16 at 10:24
  • To begin with: there are different SSL libraries, for Windows just like Linux. Windows comes with a SSL stack but not every one is using it. But what exactly is your question now about? Could you edit it to make it more specific? – phk Mar 18 '16 at 10:34
  • @phk I've made an edit, does it clearer now? – user161736 Mar 18 '16 at 12:19
1

As Dmitry commented, it is the clients (or to use the correct terminology, the relying party) that is concerned about whether the certificate has been revoked or not.

In a web server, the relying party is the browser, but if the server asks for a client certificate, then the roles are reversed and the relying party is the server.

In Windows, using CAPI, the relying party checks CRLs only if configured to do so. While I believe that IE11 on Windows 10 checks by default, I'm certain that in the IE9/Windows 7 era that you had to apply a group policy to enforce CRL checking.

Things are far more complicated in the Unix/Linux world. For a start there is no single API similar to Windows' CAPI. We have OpenSSL, GnuTLS, NSS to name but a few. Mozilla's offerings use NSS as they wrote it; Chrome uses it too. There is no guarantee that all browsers do though. Firefox checks CRLs (but not for long it seems), while Chrome uses a different mechanism, even though they both use NSS.

Just like CAPI on Windows, whether the application chooses to check CRL is up to either the vendor or the administrator (you?) or both.

  • Thanks for your detailed answer, I made an edit which now mentions that in our Linux environment we use OpenSSL. So I guess there is no easy answer for such question and I'll have to figure such matter out by checking each configuration. – user161736 Mar 18 '16 at 13:17
  • You may well use OpenSSL, but there's a very good chance that other services (such as browsers) use other libraries. Some, such as apache can be configured to use alternative libraries, but other packages cannot. – garethTheRed Mar 18 '16 at 13:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.