UKERNA have negotiated a reduced-price deal for SSL server certificates from Globalsign. The University Computing Service purchased one of these certificates in October 2001 as a test of this arrangement. Here are some technical comments on the process:
1) The deal is for Globalsign's 'standard' ServerSign certificates. This enables the highest level of encryption that is available in common between the client and the server, and I can confirm that we have observed high-grade, 128-bit encryption between recent browsers and a 128-bit capable web server. Older browsers will typically be limited to less secure 40-bit 'export grade' encryption.
[Globalsign additionally offer 'HyperSign' certificates, which use additional certificate features (variously called 'Server Gated Cryptography', 'Global-Server-IDs' 'SuperCerts' or 'International Set-Up') to enable strong encryption in what are otherwise export-crippled browsers. The UKERNA deal does not appear to include such certificates. In any case they (and their related offerings from Thawte and Verisign) are disproportionately expensive (given that they only differ from standard certificates by a few bits), and all current browsers can do strong encryption anyway. If 128-bit encryption is a required feature for a particular application then an alternative to the more expensive certificates would be to configure web servers to reject weak encryption and to recommend a browser upgrade. An alternative is to patch older browsers with 'Fortify' - http://www.fortify.net/]
2) GlobalSign's website was not particularly friendly to Unix-based Netscape (black text on dark blue backgrounds, pages - including the 'print and sign' agreement - that refuse to print, etc). I would expect that it would be better from something like Internet Explorer under Windows, so it may be best to use that to register.
3) Despite stating that original paper copies of the relevant documentation must be received by Globalsign before a certificate can actually be issued, I received mine about two hours after faxing an advanced copy to them.
4) The Globalsign root certificate is installed by default as a trusted root in most current browsers (Globalsign's site says that it is available in "Netscape Communicator starting from version 4.60. and Internet Explorer 5.01" which matches our experience). For older browsers it can be installed from Globalsign's site, though installing arbitrary root CA certificates is not something that most users should be encouraged to do. If the root certificate is missing then browser users will be taken through a series of dialogs to allow them to decide if they want to trust the site - again, this is not something that most users should be encouraged to accept.
5) Once installed, the ServerSign certificates require two intermediate certificates to link them to the Globalsign root. These can be provided automatically from the server along with the server's own certificate, but this does complicate the installation. By contrast, Thawte and Verisign certificates are directly authenticated by the the root CA certificates installed in browsers.
In addition, Globalsign's instructions for configuring Apache at http://support.globalsign.net/en/serversign/apachemodssl.cfm appear to incorrect as far as setting this up is concerned (at least, I failed to get them to work and the mod_ssl documentation is ambiguous). However Globalsign's knowledgebase article at:
does contain the correct information. I do not know how this will affect other web servers, such as IIS.
6) We have been unable to access any site with a Globalsign certificate (neither my test site nor Globalsign's own) from Netscape version 2 or 3 on any platform. According to Globalsign, this is because these browsers fail to correctly handle chained certificates. This would imply that these browsers can never work with these Globalsign certificates. It is also possible that early versions of other browsers will have the same problem, though I have yet to find any.