When you have a registered Juniper UAC / IC appliance, you have to option to download a VMWare version of the system. This is called a DTE appliance (Development and Test Environment). With this you have a full-blown UAC at your disposal for testing and development. Only downside is that it's limited to 5 connected users. Apart from that, it's just like the real-deal.
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)
By default, the J-Web interface (GUI for the Juniper SRX firewalls) has SSL enabled. Like most devices with SSL out-of-the-box, the protection is based on a self-signed certificate. Self-signed certificates are easy (they come basically out-of-the-box), but they tend to nag you every time you connect to the GUI. So, it's time to install a proper certificate.
In this case, I use the XCA (1) software to create a new certificate. This certificate is signed by my own root CA, which I installed on all of my devices and Operating Systems. Basically, I trust myself.....
According to the Juniper support pages on SSL certificate usage, I found out that the certificates are to be in the PEM format. No problem for XCA.
Today we ran into a feature of the Machine Authentication Restrictions (MAR) option in the Cisco Secure ACS Radius server. It seems that when you're using the ACS for 802.1x authentication, you have the option of demanding that the authenticating users can only be authenticated when the computer is already authenticated. This way, you make sure that no user can access the network without a legitimate PC.
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.
Today was one of those days. First the two NSMXpress appliances failed yesterday (version 2008.2r2). No way of connecting the client gui. The webinterface and SSH connections worked fine though. Picked one up for examination, and since I had some *cough*good*cough* experiences a while back I assumed the latest software had some undocumented bug.
A back to factory defaults (version 2007.3r1) worked fine, but due to certain hardware the 2008 version was needed. So I upgraded the appliance (again) and found (while waiting) that the security certificate, used between the NSM server and the client gui, had expired on Juli 20th, 2009....... So someone forgot to update the certificates in the 2008.2r2 software.
After fixing that, the client gui worked like a charm.
After my blog post on OSX and Aladdin eToken I received a phonecall from Haaino @ AET Europe. He offered the SafeSign software for OSX so I could try their OSX software as well.
The SafeSign software is used with smartcards and smartcard readers like the OmniKey smartcard readers. Through my line of work, no lack of smartcards and/or readers. Only the software was missing (up till now).