17.5 When Things Go Wrong

only for RuBoard - do not distribute or recompile

17.5 When Things Go Wrong

When a web browser makes a connection to an SSL web server, it checks on a number of the fields in the server's X.509 v3 certificates. If the contents of a field don't match what the web browser expects, it can alert the user or disallow the connection.

This section summarizes some of the problems that can befall even the most well-intentioned site administrators.

17.5.1 Not Yet Valid and Expired Certificates

When a web browser opens an SSL connection to a server, it checks the dates on the certificates that the server presents to make sure that they are valid. If the certificate has expired (or if the client's clock and calendar are not properly set), it will alert the user. Some programs that use SSL simply inform the user that a certificate has expired (or is not yet valid) and give the user the option to continue. Other programs do not give the user the option.

If the date on the certificate looks valid, then it is possible the date on the user's computer is wrong for example, the clocks of many desktop computers will reset to 1980 if their internal battery dies. If you can't figure out why a certificate is out of date, check your computer's clock.

17.5.2 Certificate Renewal

Like most other identification documents, X.509 v3 certificates expire. When they expire, you need to get new ones if you wish to continue to offer X.509 v3-based services. In many cases, you can simply request that a new certificate be issued for your existing public key.

The authority that issues the X.509 v3 certificate determines when the certificate will expire. These days, most third-party CAs seem to be issuing certificates that expire one year after the date on which they are signed. Why pick one year? Here are some practical reasons:

• The longer a certificate is used, the greater the chance that its associated private key will be compromised.

• The speed of computers and our knowledge of public key cryptography are both improving rapidly. A secure certificate that is signed today may be unsecure in two years because of advances in technology. Short expiration times therefore increase confidence in the public key infrastructure.

• Business licenses tend to be for a period of one or two years. If a business license is used in part to validate a certificate, it seems unreasonable to issue a certificate that outlives these master documents.

• Most third-party CAs are selling certification services. Selling a certificate that expires in one year means that you can count on a steady revenue stream from certificate renewals roughly a year after you first go into business.

• Having a certificate expire once a year assures that companies that fire their webmasters and don't hire anybody new will be suitably punished before long.

Be sure to obtain a new certificate for your organization well before your current certificate expires!

Remember, it is the SSL client that determines whether or not a server's certificate has expired when it connects to the server. Thus, clients that have their clocks set incorrectly frequently report that a server's certificate has expired, when in fact it has not.

When you apply for your new certificate, you may wish to request that it become valid before your current certificate expires. Otherwise, some users may be locked out of your web site when you change over from one certificate to another, because they have slightly different ideas of what time it is. For safety's sake, certificates should be replaced at least 36 hours before they expire.

Some SSL servers allow you to equip them with multiple server certificates. These servers must be running SSL 3.0 or above to download multiple certificates over a single SSL connection.

17.5.3 Wrong Server Address

Web server certificates contain a special field that indicates the Internet hostname of the computer on which the server is running. When a browser opens an SSL connection to a web server, it checks this field to make sure that the hostname in the certificate is the same as the hostname of the computer to which it has opened a connection.

The purpose of this check is to ensure that certificates will be used only on the particular machine for which they are issued. This allegedly provides more security: through an attack called DNS spoofing, it's possible to confuse the client computer's system that translates between domain names and IP addresses. The client thinks it is jumping to a particular web site, like www.ibm.com, but it's really jumping to a pirate computer connected to a stolen dialup in Argentina.

This checking of server addresses doesn't really provide any more security, because domain names themselves don't really provide a form of identification. For example, the Sony corporation operates the domain names sony.com and sonystyle.com, but in July 2001 the domain name sonyshop.com belonged to Peter Beerten in Tervuren, Belgium. (Mr. Beerten apparently got the domain in August 1998, as shown in Example 17-4.)

Example 17-4. Sonyshop.com doesn't belong to Sony Corporation, but to Peter Beerten!

> whois sonyshop.com ... Registrant: Peter Beerten (SONYSHOP-DOM)    Heide Street #1    Tervuren, Belgium 3080    BE    Domain Name: SONYSHOP.COM    Administrative Contact, Billing Contact:       Beerten, Peter  (PB6745)  [e-mail]       Peter Beerten       Heide Street #1       Tervuren, Belgium 3080       BE       32 2 720 7071 (FAX) 32 2 720 9192    Technical Contact:       Hostmaster, Verio  (TH941)  [e-mail]       560 Gateway Drive       Napa, CA  94558       US       707 521-5400 707 251-3080    Record last updated on 25-Aug-2000.    Record expires on 25-Aug-2001.    Record created on 25-Aug-1998.    Database last updated on 8-Jul-2001 03:05:00 EDT.    Domain servers in listed order:    NSX.NTX.NET                  209.1.144.216    NSC.NTX.NET                  128.121.247.244 > 

Instead of validating DNS addresses, web browsers should actually display the distinguished name on the certificate prominently. Sadly, both Netscape and Microsoft have hidden these fields from the certificate in another window that most users don't even know about.

Because SSL validates the checking, you will need a new certificate if you change the name of your web site. For example, if your web site is at www.company.com, and you decide the www is silly and want to allow people to type just company.com, you will need a separate SSL certificate for the company.com domain if you intend to use that domain with SSL. An easy way around this is to rig the HTTP server to automatically redirect users who type company.com to www.company.com.

only for RuBoard - do not distribute or recompile