I would like to implement an internal site for our company, with certificate authentication used wherever possible. I have run into (and tried) various examples where one creates their own self-signed CA for everything, but this is not what I want.

For reasons of security, I do not want to develop this with our actual wildcard site certificate - the less servers that have the private key file on, the better. What I'd like to do is this:

a) Use a self-signed CA and sign the SSL certificate used for HTTPS, and add it to my system certificate store. For the purposes of this adventure, this would be the first CA, or ca-1.

b) Use the CA that issued our S/MIME certificates for authentication (they are the correct type!) Certificates for this purpose (client authentication) would be issued by the second CA, or ca-2.

Eventually, after development is complete, I plan to replace the site and ca-1 certificate for a) with those from our SSL certificate provider for end-user convenience and security, but for the purposes of development of user authentication, I'd like to use my real certificate, because only the public key will be stored on development servers - and from a development point of view, it's more useful to work with the real thing.

From the point of view of being able to choose separate CAs for SSL/TLS and authentication, I'd also be interested in finding out how to make this work. (That's just good old-fashioned curiosity.)

My HTTPd configuration (/etc/httpd/conf.d/site.conf) looks a little like this:

<VirtualHost *:443>
  ServerName site
  DocumentRoot /srv/site/www
  SSLEngine On
  SSLProtocol all -SSLv2 -SSLv3
  SSLHonorCipherOrder On
  SSLCertificateFile /etc/pki/tls/certs/site-1.crt
  SSLCertificateKeyFile /etc/pki/tls/private/site-1.key
  SSLCertificateChainFile /etc/pki/tls/certs/ca-1.crt
  SSLCACertificateFile /etc/pki/tls/certs/ca-2.crt

<Directory /srv/site/www>
  Require all granted

<Directory /srv/site/www/secret>
  SSLVerifyClient require
  SSLVerifyDepth 1
  SSLOptions +StdEnvVars
  SSLVerifyClient require
  Require all granted

<VirtualHost *:80>
  ServerName site
  RewriteEngine On
  RewriteRule ^(/.*)$ https://%{HTTP_HOST}$1 [redirect=301]

I'm also aware that one needs to use a restorecon -RvF /srv for SELinux (and I have done this.)

The idea is to have an open splash page, so graphics can be shown even to unauthenticated users (together with a helpful reminder to install a certificate on their computer before trying again, rather than simply showing them a 403 Forbidden page.) The content in the /secret directory within the document root, however, is to be shown only to authenticated users. A small amount of PHP on the spash page would detect the availability of content in /secret, and redirect the user automatically.

The plan is to have HTTPd only authenticate users who have a certificate that's signed by our CA (that would be ca-2.crt in this example), and the Web application would have to check that the organisation (O) in the certificate is ours, of course. After that point, once the application is satisfied about the CA and the O (organisation), the CN (common name) in the user's certificate, shared by their browser, would then be used to authenticate them, possibly using the OU (organisational unit) to segregate rights according to department.

Like many ideas, this seemed a fine one - at first glance, anyway. In practice, however, it did not work out quite as intended: My browser simply shows me a 403 Forbidden error, with seemingly nothing in /var/log/httpd alluding as to why. Content outside /secret, of course, works fine.

The site-1.crt and site-1.key pertain to ca-1.crt. ca-2.crt would be the CA that has signed the private key ensconced on my smartcard (which my host OS knows about: I have already used it to sign and encrypt e-mail, log in to servers via SSH, et cetera, so I'm quite sure it works.)

I would also be prepared to accept having to add the public keys of all users to a list, which HTTPd would authenticate against. Not quite as convenient, but certainly secure (and it would also allow more fine-grained access, rather than simply allowing the whole company - or a whole department - access to the resource.)

Any assistance in this adventure would be greatly appreciated.

  • Looks good to me. Does the browser prompt you to pick a certificate or is it directly 403? I'd blindly try SSLVerifyClient optional in the entire VHost, maybe the renegotiation aspect doesn't work. Other than that, LogLevel ssl_module:trace4 will give you more log output. – Ulrich Schwarz Oct 5 '18 at 16:15
  • The 403 error is immediate: I'm not prompted for a certificate. This was using Chrome and Internet Explorer on Windows 7. The server OS is RHEL 7.5. – Oliver Jones Oct 8 '18 at 18:46
  • If you are still working on said project above... I think you're missing information on how you are authenticating the user... Here's apache's mod_auth page. – RubberStamp Nov 9 '18 at 3:40

Your Answer

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

Browse other questions tagged or ask your own question.