In my line of work I get to work with a lot of security devices which run self-signed certificates. Those certificates are most of the time generated when the device / appliance is installed, or configured for the very first time. When you connect to one of those devices with a web browser, you tend to see the warnings displayed by the browser that the connection is not to be trusted.
In Firefox, you can add an exception in the browser. When you've done that, the next time you go to the website, the browsers treats the website as trusted.
When you install a Perfect Server based on Centos and ISPConfig v3.x, the system / 'installer' creates for the components self-signed certificates. All these certificates will generate different warnings in your browser, mail clients etc. So time to eliminate those warnings.
First I needed to find out where all those certificates are located, and what there formats are. In my case, there are three services that use SSL/TLS in some form;
- Postfix SMTP service
- Courier IMAP service
- http / Apache2 webservice
Checking the configuration files will reveal their locations.
A fairy long title, but it describes exactly what this post is about. Once again a post about a Microsoft product and the way it works (or rather doesn't work) with your average Internet standard.
This week I was busy with RADIUS, 802.1x, PKI and the protection of websites with SSL encryption. For the implementation of 802.1x, I needed a PKI environment, so I used the Microsoft Certificate Services for that purpose. Along the way, I needed an SSL certificate for an internal website, but this particular website needed to work properly based on different FQDN's and or IP addresses without throwing warining or errors regarding the SSL connection.
The way to do this is to add Subject Alternative Names (SAN) to the certificate. This enables you to access the website in different ways, e.g.;
- Access a webmail host from the internet based on its official FQDN (https://webmail.somedomain.com)
- Access the same webmail host from the inside of the corporate lan based on its internal name (https://webmail.acme.local)
- And access the host from legacy DNS-unaware software on its IP address (https://192.168.1.254)
We've been experimenting with with the use of user certificates for VPN access to the lab. Issuing, and using them isn't the problem. The problem is that there's no way of enforcing a password on the use of the private key. You can use private key protection on the certificate template, but that still doesn't enforce a password requirement. The user still has the option to choosing for the notification instead of a password.
Certificate Template - Request Handling OptionsThere's an option to enforce a password, but that's system wide for the Microsoft Cryptographic Service Provider, and we don't want to enforce passwords for ALL certificates. We just want to enforce passwords for this specific template.