SSL And Beyond, Part 2: Compatibility & Deployment Across the Board

In our first installment we discussed the origins and development of the Secure Sockets Layer (SSL) protocol and considered its role in providing secure internet connections through encryption and the use of digital certificates.

In this article, we’ll go further into the use case to discuss how applications are deemed compatible with SSL, and how the protocol is deployed in the field, on various platforms.

Compatibility? Why all the Fuss?

Secure connections are essential – especially if you need to transmit sensitive information such as personal data or credit card details over the internet. An encrypted exchange of data is called for, and SSL (Secure Sockets Layer) and TLS (Transport Layer Security; a successor to SSL) are the protocols by which this encryption can take place.

Users now connect to e-commerce sites and other web resources in a variety of ways, so the pressure is on the owners of these sites to make sure they are accessible to all their actual and potential customers.

If secure transactions are on offer via SSL or TLS (and with users demanding maximum security, they should be), an organization’s identity will have to be verified by its having a valid digital certificate. And these certificates need to be recognized by every browser, mobile device, or operating environment that their customers use.

Securing Confidence

Just to recap, here’s what happens in a typical case when a secure connection is established using SSL:

1. The user’s web browser asks for identification, before attempting to connect to a server protected under SSL.

2. The web server sends a copy of its SSL certificate to the client’s browser.

3. The user’s browser compares the certificate to its internal database to determine whether it is trustworthy. If so, the browser sends a message confirming this to the server.

4. The server acknowledges receiving this message by sending back a digitally signed message of its own, and confirms that SSL encryption can commence.

5. Encryption keys are employed on both sides, and scrambled data is communicated between client and server.

Note that the critical stages are 1, 2 and 3. Once the client’s browser requests an ID, if the server’s certificate isn’t recognized (or has expired, or been revoked), then no further exchange will take place.

Certificate Compatibility

SSL certificates must conform to the industry-wide X.509 standard. Today, most certificates can enable strong encryption to 128-bit level, with some capable of 256-bit encryption. In encrypting and decrypting data (a mathematical process), the number of bits corresponds to the length of the encryption key. Longer keys make more combinations possible and allow for stronger encryption.

Digital certificates used in SSL are purchased from a third party known as a Certification Authority (CA). The CA validates the information attached to a certificate, which is a formal statement of the identity of the organization or person who wants to be authenticated.

The AICPA (American Institute of Certified Public Accountants) has set the WebTrust standard, to which vendors of SSL certificates must comply. Each Certification Authority is assigned a Root Certificate status. The major browser manufacturers maintain a “trusted Root Certificates” list, which ships within their software.

SSL certificate compatibility is measured by the number of browsers that automatically include the linked certificate within their trusted Root Certificates store. Most commercial Certification Authorities issue certificates compatible with at least 99% of all major browsers. This is known as 99+% compatibility.

Intermediate Certificates

In some cases, a Certification Authority will issue its SSL certificates progressively. A subordinate document called an Intermediate Certificate may be issued, as part of a “chain of trust” linking back to the trusted CA Root Certificate.

This is done as a security precaution, on the part of the CA. When SSL certificates are generated directly from the Certification Authority’s Root Certificate, this increases the risk that the Root Certificate may be accessed by malicious outsiders. No problems with installation, compatibility, or performance are experienced by the client when Intermediate Certificates are used.

Certificates: Expiration and Renewal

Regarding SSL certificate expiration and renewal, certificates are issued with a set period of validity and they can no longer be used for securing communications once this expires. A Certification Authority will usually send out a renewal notice before the expiration date. Typically, certificates can be renewed up to 120 days before and 30 days after their validity expires.

If the terms of their use are abused or contravened, SSL certificates can also be revoked by the issuing authority. CAs maintain a Certificate Revocation List (CRL), which is used by client’s web browsers to check a certificate’s validity.

The Online Certificate Status Protocol (OCSP) is being adopted by an increasing number of new browsers. As its name suggests, this is a web resource providing a one-stop check on the status and validity of SSL certificates.

Browser Compatibility

For browsers, a compatibility of 99+% means that a Certification Authority’s digital certificates sit in its trusted Root Certificates store, having been approved by major vendors like Microsoft (Internet Explorer and Spartan), Apple (Safari), Google (Chrome), Mozilla (Firefox), or Netscape (Communicator).

A browser assesses whether or not an SSL certificate is trustworthy based on the CA that issued it. A certificate issued by a known and trusted Certification Authority inspires trust in the website which is SSL-secured by it. Conversely, a self-signed certificate may raise a red flag, as would an SSL certificate issued by an unknown or untested CA. In this case, a real-time security alert may be displayed in the user’s browser window.

So an SSL certificate’s browser compatibility (also known as its level of browser recognition or root ubiquity) is a measure of the number of browser vendors that trust the CA.

Unless the browser on a client’s system is a really old version, compatibility is unlikely to be an issue over time as Root Certificates are updated frequently.

Server Compatibility

For compatibility with SSL, servers don’t require Root Certificates to be embedded within them. Assuming it’s installed correctly, a server will work with any certificate signed by a CA (known and trusted, or not). The rare exceptions are the small number of servers, which only support unchained certificates.

Once installed on the server, an SSL certificate and any Intermediate Certificates that may be associated with it can be sent to a client that calls for it. It’s then up to the client’s browser to check its Root Certificate store to see if the SSL certificate can be trusted.

Compatibility Over Multiple Domains

A single SSL certificate usually secures one URL or domain name. Each certificate is bound to that domain, and changes in the domain name must be reflected by adjusting the certificate. If you have several domains to cover, purchasing and managing SSL certificates for all of them can become a major chore.

Multi-Domain Certificates can save time and money by allowing multiple URLs to be covered by a single document. They are sometimes known as Subject Alternative Name (SAN) certificates, or Unified Communications Certificates (UCC, or UC Certificates).

Users of Microsoft technologies like Microsoft Exchange Server and Microsoft Communications Server typically have many associated services requiring the security of SSL encryption. For them, UC Certificates are essential to securing internet access for clients and servers.

Organizations that use more than one Unified Communications platform (e.g. Microsoft Office Communications Server and Google Apps) also need Multi-Domain SSL certificates to validate connections between servers across the different platforms.

Another use case would be that of a company which has multiple domain names, which point to the same website. This might occur with branch offices in different countries (with their associated suffixes like .co.uk, .de, etc.), or an organization having several top-level domains (.com, .net, .org, etc.). With a UC Certificate, all the domain names can be covered at once.

Within the enterprise, Multi-Domain Certificates can be used to secure multiple internal IP addresses and server names to allow remote access by SSL from outside the corporate firewall.

A Multi-Domain Certificate must conform to the X.509 standard and provides the same level of encryption as a single user certificate. But for a UC Certificate, the Subject Alternative Name (SAN) extension lets the user specify a list of values pointing to resources that will have SSL protection.

Since the SAN comes under X.509 standards, it can be read by the majority of web browsers and mobile devices.

Wildcards

Unlike a UCC, a Wildcard Certificate can protect an unlimited amount of sub-domains, which can be specified in the form *.subdomainname.com. Wildcards are however restricted to sharing the same domain and the same number of levels.

Multi-Domain Certificates don’t have this limitation. But there’s an upper limit to the number of domains that can be protected; namely, the number of SANs you can afford to buy from the Certification Authority.

Note that while most mobile devices will accept Wildcard Certificates, the asterisk symbol (*) used in the Common Name field of the SSL certificate may throw up an error message.

Mobile Compatibility

As far as mobile devices are concerned, newer is better. Cell phones, tablets, and phablets are harder to update than web browsers on desktop or laptop systems. So you tend to find a more up to date store of Root Certificates on newer model devices.

Most of the major CAs and providers of SSL certificates are compatible with the latest models from manufacturers such as Windows Phone, iPhone, Android, and Blackberry. If support for older devices is required, there are online resources listing certificate providers, and their degrees of compatibility. These should be consulted first.

Building Apps, for SSL Compatibility

Incorrect or inappropriate use of Application Programming Interfaces (APIs) and Software Development Kits (SDKs) are the most common reasons for the poor implementation of SSL or TLS procedures in mobile applications. In developing mainstream apps (not browsers, which don’t usually have this problem), certain precautions should be taken to prevent the interception and modification of data by unscrupulous users.

A certificate “identity chain” should be built up, confirming trusted links to the ultimate or end-entity SSL certificate. This chain may be constructed from extension values like the authorityKeyIdentifier/subjectKeyIdentifier (AKI/SKI). Alternatively, the Issuer Distinguished Name / Subject Distinguished Name values (IDN/SDN) may be used.

The links between the end-entity SSL certificate, any Intermediate Certificates issued by a CA, and the Root Certificate should be verified by cryptographic means. It’s best to require the end-entity certificate to link to a particular trusted Root Certificate, and it should bear a signature from an Intermediate Certificate having a specific Common Name.

Applications should be able to verify the notBefore and notAfter time, for all certificates in the chain. This can be linked to the time-keeping functions of a mobile device. Apps should also be able to recognize critical extensions in a certificate, and any special policy provisions that apply.

Compatibility in the Lab

Network infrastructure and other environmental conditions will vary from organization to organization, but developer Tristan Watkins favors the use of an internal Certification Authority over self-signing certificates in the lab.

Active Directory Certificate Services (AD CS) are one solution, whose Root Certificates are already trusted by most domain servers. Even with non-domain systems, trust only needs to be established once with the Root CA rather than for each individual certificate case.

If self-signed certificates are employed, manual adjustments will have to be made to put them on the trusted list each time a new user account is created, or a new virtual machine is put in place. These steps will have to be retraced once each self-signed certificate expires.

The AD CS certificates have a default expiration period of two years, but it’s possible to extend that period by tweaking the operating environment with a new template. AD CS certificates also have support for Certificate Revocation Lists (or CRLs). This is a hedge against an SSL connection being refused by clients whose machines might otherwise be unable to confirm whether or not an SSL certificate is still valid.

Application production infrastructure can also be emulated by Active Directory Certificate Services more easily than self-signed certificates, which may not be able to use Subject Alternative Names (SANs) instead of wildcards.

For the Enterprise: Some Best Practices

Co-ordinate with your vendors to make sure that your web servers are kept up to date with the latest versions of SSL or TLS.

Especially if you’re involved in e-commerce transactions, buy your SSL certificates from a CA with a strong security presence and good reputation. These High Assurance providers should also give 99+% browser compatibility.

Check their pricing policy on multiple domains. The base price quoted by some suppliers only includes a few names, with additional ones attracting fees that may be prohibitive.

Where possible, go for self-service options. These will let you modify an SSL, add or remove domain names etc., without having to put in a service request.

If you need to secure a large number of publicly accessible web pages, an Extended Validation (or EV) certificate is worth considering. EV certificates will display a green address bar in your visitors’ browser windows when an SSL connection is made. This visual mark of additional security is also backed by a more rigorous verification process than that used for standard certificates.

In our next installment, we’ll consider the future of SSL, and just how far it might go in the overall scheme of things. Hope you’ll be here for that.