Sole's Blog

Posts Tagged ‘ssl’

Having spent some time trying to install an SSL certificate from a trusted certification authority on this product, I felt I should share my findings as they might save someone else the headaches and time I had to spend on this.

For reference I used a ZyXEL ZyWall USG 300 with Firmware version: 2.20(AOE.6) / 1.11 / 2011-10-05 11:51:34

I assume this information is the same for pretty much all versions of ZyWall products, but I can not confirm this from own testing as I only had access to one edition.

About Intermediate SSL certificates

All certificates today that want to enjoy the WebTrust approval must use intermediate issuing certificate authorities, this means that a root certificate is no longer allowed to directly issue server certificates for customers. This makes good sense security wise, as it is much harder for a hacker to gain access over the root certificate when it is not online and in case of a compromise, it should be sufficient to close the intermediate, without having to “remove/uninstall” the root from every client in the world.

So most professional products around that uses SSL certificates must be able to install both a server certificate and the intermediate issuing certificate, because the client only knows the root certificate, it needs the server to give it both.

Installing SSL certificates on ZyXEL ZyWall USG 300 (the good part)

Go into Configuration -> Object -> Certificate

Some things to have in mind when installing Read the rest of this entry »

I always wanted the ability to compare different SSL certificates with the clients that do or do not support them.

But at best you can download the roots that a mobile client, browser or operating system uses and compare them with the certificates issued by thoose roots. A cumbersome and extremely tedious task, that still only gives you information about 1 single client. Why has no one made a database containing all popular SSL certificates and clients/browsers/mobile phones and their compatibility.

Well I guess the reason is that it is extremely hard to get a consistent and easy to use data from the clients. The issuers only have information about what clients support them, but the information is usually not quite true, i.e. SSL provider X gets approved by Nokia, so they write now they are supported by Nokia, but that is only true for new nokia phones made after the approval or updates and even in some cases Nokia might forget the SSL provider in a new phone model…

So I tried the next best thing, i created a web page that will test SSL certificates and if they work on any client. Basicly it looks for a small image on a webserver with the SSL certificate, and records if the client was able to load the picture via javascript. The result is then shown on the webpage and stored for a future comparison chart when I have enough clients/SSL certs.

I need your help

But I could realy use some help, I need people to run the test with their different clients, operating systems, mobile phones, etc. so we get as much data as possible.

You can start the test from this page www.ssltest.net/compare/

I also need more SSL certificates to add to the test. If you have or know of a publically available server using a SSL certificate not in the test allready, please e-mail me the URL for a small image of at least 2×2 pixels plus the name of the SSL certificate in use to sole@sole.dk

I hope the results will give enough data to make a public and FREE database of what SSL certificates that work on different browsers, operating systems and mobile phones.

Update 1 jan. 2011.

First results of the client SSL compatibility comparison charts are now public live on www.ssltest.net/compare/sar.php the page is not finished and only shows correctly in IE7+ (not doing layout, etc. before functionality is complete). But there is allready data about different OS, browsers and mobile phones that work or do not work with different SSL certificates. I must admit that the information is surprising for some of the results and I am sure that with more data it will get even more interesting. I have not found another place on the internet that has this information.

Been reading up on external and internal DNS names used by OCS 2007 R2 ? Your head stopped spinning yet? So you’ve decided on what FQDN’s to use, next step order some SSL certificates, should be easy enough right, You allready figured out You need SLL certificates that are Unified Communications Certificates (UCC) enabled. In my example I will use GlobalSign Domain Validated SAN’s, if I needed multiple domains for example for @sole.dk and @soleit.dk, I would choose GlobalSign Organisation Validated SAN’s instead.

For a GlobalSign SSL certificate to be UCC enabled, it must use SAN domains, no other way of enabling it. So no point in spending lots of budget on seperate SSL certificates for each service. SAN Subdomains are also quite alot cheaper than buying seperate SSL certificates.

One of the tricky parts of Office Communications Server 2007 R2 and SSL certificates, is that You can not use one single SAN SSL for all services, if You intend to use port 443 for all services!

Why would we only use port 443 ? Read the rest of this entry »

The easiest way (I love easy!) to order and install an SSL certificate on Exchange 2007, is to order a SAN (Subject Alternative Name) certificate with AutoCSR meaning you dont have to create a CSR but instead get a certificate backup file (PKCS#12, P12. PFX). You also save time with the SAN because you only use one certificate for all services and can move services from one domain to another in the certificate with no problems.

Make sure you get a SAN certificate including the full domain name(s) you use to access Outlook Web Access, Outlook Anywhere, Autodiscover and any internal servernames using the certificate (usually free).

The Certificate you order should contain something like this:

• mail.sole.dk and/or owa.sole.dk – for Outlook Web Access
• autodiscover.sole.dk and any other e-mail domain you use with Autodiscover/OA.
• MYSERVER01 and MyServer01.domain.local - and any other internal servername that will be using the certificate

Personally I setup servers to respond only to OWA and ActiveSync on the mail./owa. domain, and use all other services like Outlook Anywhere, etc. on the autodiscover. address, this way I can use Forms Based Authentication/Basic with my OWA/ActiveSync website, and NTLM with my other services. You can see more information about this from my previous blogs here. Some people argue for and against having internal server names in the certificate, but I figure if they are free anyways, and might help why not add them – and if security is so much an issue that internal server names must not be revealed, you have other much bigger problems anyway.

Now some simple commands to manipulate Exchange 2007 SSL certificates. (Stolen from the danish Exchange 2007 guide on FairSSL, I co-authored the manual) Read the rest of this entry »