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.
It has finally been done. I've switched off the old Windows 2003 server at home and officially replaced it with an Apple Mac mini server. For now... And with 'for now' I really mean for now. It turns out that Apple OS X Server doesn't resemble its client counterpart at all. Where the client is stable and intuitive, the server edition lacks both.
I'll try to explain why I think there's lots of room for improvement. Mainly stuff I ran into while configuring the server/services.
Since the Windows fulfilled several functions, I needed these functions to be available on the OS X server as well. These were;
- Networking services like DNS and DHCP
- Webserver
- Mailserver
- MySQL Database
- SSH Server
- File sharing on the internal network
- Public Key Infrastructure for issuing certificates
- Download station
Evaluating these functions, one would think that this shouldn't be a problem. Well it actually is.... At least some of those features.
;)
;)