CRL check for Estonian ID cards fails

[edgars.buss.optibet.lv@…]

Nginx CRL for Estonian ID card fails with error:

2016/10/04 08:02:13 [info] 7#7: *8 client SSL certificate verify error: (3:unable to get certificate CRL) while reading client request headers, client: 192.168.2.133, server: site, request: "GET / HTTP/1.1", host: "site"
192.168.2.133 - - [04/Oct/2016:08:02:13 +0000] "GET / HTTP/1.1" 400 231 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0"

Relevant config :

  listen 443 ssl;

  ssl_certificate     /etc/nginx/site.20150819.chained.crt;
  ssl_certificate_key /etc/nginx/site.20150819.nopass.key;

  ssl_verify_client on;
  ssl_verify_depth 2;

  ssl_client_certificate /etc/nginx/ee_all_20161004.pem;
  ssl_crl /etc/nginx/ee_all_20161004.crl.pem;

Here are links for certificates and CRLs;
​https://sk.ee/en/repository/
​https://sk.ee/en/repository/CRL/

I converted CRLs from DER to PEM and concated to one file in the same order as client certificate.

Nginx perfectly validates client certificate if no ssl_crl config is specified thus disabling use of CRLs. One note that combined CRL is more than 50MB in size.

[Maxim Dounin]

The message suggests CRLs for some of the certificates in the chain are not available in the CRL file you've created. If you need help, consider asking in the ​mailing list.

[edgars.buss.optibet.lv@…]

The message is saying wrong. As I have checked and tested multiple times. CRLs are included for all presented certificates in chain: 1 for root and 3 for itermediate certs.

I'm providing a link to the files used for ssl_client_certificate and ssl_crl directives.

​https://yadi.sk/d/TzxYRLmewFRHk

There is another developer who could not get CRL verification for EID working:
​https://github.com/konstantint/eid-webauth-samples/blame/master/nginx/ssl-site#L11

[Maxim Dounin]

The provided archive does not contain the client certificate used for authentication, and thus it is impossible to tell if the configuration is correct or not.

As previously suggested, the message logged indicates that some of the certificates in the chain do not have corresponding CRLs available in the CRL file you've created. And from the information provided there are no reasons to assume this is not true.

You may try to look into ​debug log for additional information about verification of client certificates, it will show detailed information of all certificate verification steps, as well as all errors detected.

[Maxim Dounin]

Feedback timeout.

[Maxim Dounin]

Just for the record, it looks like the problem with the root certificate CRL, see ​http://mailman.nginx.org/pipermail/nginx-devel/2017-March/009609.html.

The root certificate, "EE Certification Centre Root CA", has a CRL available at ​http://www.sk.ee/repository/crls/eeccrca.crl. This CRL lists Issuing Distrubution Point extension as follows:

            X509v3 Issuing Distrubution Point: critical
                Full Name:
                  URI:http://www.sk.ee/repository/crls/eeccrca.crl

But there are no CRL Distribution Points in the certificate itself. As a result, OpenSSL refuses to to use this CRL when it tries to verify more than just a leaf certificate, for example:

$ openssl verify -CAfile EE_Certification_Centre_Root_CA.pem.crt -CRLfile eeccrca.crl.pem -crl_check_all KLASS3-SK_2010_EECCRCA_SHA384.pem.crt
KLASS3-SK_2010_EECCRCA_SHA384.pem.crt: C = EE, O = AS Sertifitseerimiskeskus, CN = EE Certification Centre Root CA, emailAddress = pki@sk.ee
error 44 at 1 depth lookup:Different CRL scope

This probably should be reported to the sk.ee team, likely they want to fix this. Simply removing the IDP extension from the CRL should do the trick.

[jyrno42@…]

I will contact SK.ee to get their stance on this issue.

[jyrno42@…]

Also, the official ​IDCard Apache setup guide (page 4) contains the following lines in the configuration:

SSLCARevocationCheck leaf

which indicates that someone on their side might be aware of the problem already.

[Maxim Dounin]

Given the same document also suggests to use SSLUseStapling for client certificate revocation checks, I doubt it was something seriously looked into. Contacting them directly certainly won't hurt.

[jyrno42@…]

Adding the response i got from SK.ee for future wanderers.

Translated response:

Hello,

thanks for pointing out this issue, however we are already aware of the fact
that the root-certificate "EE Certification Centre Root CA" is missing
DP (Distribution Points) attribute.

Removing the IDP from the CRL profile would probably work as a temporary 
solution, but at this time we are not fully aware of the effects of this 
and we need to test it.

Due to this we currently have in our installation guide
http://www.id.ee/public/Configuring_Apache_web_server_to_support_ID.pdf 
the parameter SSLCARevocationCheck set to "leaf"
(https://httpd.apache.org/docs/2.4/mod/mod_ssl.html)
 
Mihkel T.
Integraator
SK ID Solutions AS

Original text in Estonian:

Tere,

täname, et juhtisite sellele probleemile tähelepanu, aga oleme juba teadlikud, 
et juursertifikaadis "EE Certification Centre Root CA" DP (Distribution Points)
atribuut puudu on. Võimalik ajutine lahendus ehk on IDP eemaldamine 
tühistusnimekirja profiilist, aga hetkel ei tea milline on selle mõju, 
peame seda testima. 

Hetkel on sellepärast juhendis 
http://www.id.ee/public/Configuring_Apache_web_server_to_support_ID.pdf 
parameeter SSLCARevocationCheck väärtusega "leaf" 
(https://httpd.apache.org/docs/2.4/mod/mod_ssl.html)
 
Mihkel T.
Integraator
SK ID Solutions AS