☰

Apache and support for per-directory CA

tag-icon • tag-icon linux debian apache-http-server ssl
Apache and support for per-directory CA

I was using Debian Wheezy with Apache and I configured some paths in SSL to be protected by client certificate.

   <Location /admin-page>
     SSLCACertificateFile    /etc/apache2/ssl/leos.pem
     SSLVerifyClient require
     SSLVerifyDepth  0
     SSLRenegBufferSize 10486000
   </Location>

Since I upgraded to Jessie I cannot start Apache2 unless I comment out this part.

Mar 20 16:38:07 apache2[1649]: AH00526: Syntax error on line 51 of /etc/apache2/sites-enabled/default-ssl.conf:
Mar 20 16:38:07 apache2[1649]: Your SSL library does not have support for per-directory CA

How can I get it back working?

答案1

You need to move the line "SSLCACertificateFile /etc/apache2/ssl/leos.pem" outside the Location stanza (put it alongside your SSLCertificateFile file). If you already have an SSLCACertificateFile - for example used for SSL certificates from an external company - and want to add a self-signed CA for client side authentication, simply add your CA certificate to that file (a single .crt file can - and often does - have multiple certificates).

You can still only force verification for the directories you want to protect.though, with a Location stanza like:

<LocationMatch "^/(admin|internal)($|/)">
          SSLVerifyClient require
           SSLVerifyDepth 1
           SSLRequire (    %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \
           and %{SSL_CLIENT_I_DN_O} in {"CompanyName} \
           and %{SSL_CLIENT_S_DN_OU} in {"OU1","OU2"} )
</LocationMatch>

I see no reason why this would not work with Location rather then location match, but I've not tried that. I use location match because I've implemented it on the proxy.

You can also get rid of / change the SSL_CLIENT_* lines to match your certificate. In one place I work we have different types of certificates for different people, with different permissions - identifying the Organisation Unit, along with appropriate certs allows different groups different permissions - which translates to access to different locations.

I note that the same VM Container is used by end users without a cert - of-course they can't access the parts with "SSLVerifyClient require".

相关内容