Public Key Certificates

From DreamHost
Jump to: navigation, search

Public key certificates allow the secure communication between server services and client applications. With proper certificate cycle management, certificates also ensure the authenticity of parties communicating over networks. In other words, receiving a verifiable certificate from a server helps a user verify that they are communicating potentially confidential information with the authentic identity, they seek to communicate with.

{The secure protocols--ssh, scp, sftp, putty, ...--automatically use public key certificates for verifying the remote host's identity. And they use a public/private key scheme for logging in without giving passwords. See SSH.}

Problem

When two parties wish to communicate securely through encrypted channels, several issues can arise. First, both parties must ensure the other party is the authentic person or organization with whom they want to communicate. This can be a problem even in face to face communication, if for example, the two parties have never met before. In the movies this is solved by men in trench coats where one says to the other “the fat man walks alone.” The other man whispers “but only when it’s raining.” This prearranged exchange of “keys” or “pass phrases” that presumably would not happen randomly let’s each man know they're communicating with the authentic contact they expected.

However, over the Internet, the problem becomes more acute. In this case, there’s no physical presence so even life-long friends have no way of authenticating each other like they could easily do face to face. If one friend sends another friend an email, how can the one be sure the message came from the other? If they want to be able to send messages securely encrypted, this too raises complications since each would have to meet to exchange the encryption keys..

Solutions

In comes certificates to solve many of these problems. However, many issues still exist with certificates. How do the certificates get issued? Who issues them? How does the issuer establish a secure channel with the issuee? How can the issuer of a certificate know the authentic identity of the individual they issue the certificate to.

This all needs to be managed with certificates and is sometimes called the certificate management cycle. The cycle is sometimes managed by a certificate authority, or CA for short. The CA can either be a third-party CA who the public has come to trust through the settings of their operating systems and internet applications. Other CAs may be a particular designated person or department within an organization or community of individuals. Yet another way to issue certificates is through a scheme called web of trust, where on person certifies another who certifies another and so on. Each of these approaches has benefits and drawbacks for certificate management.

The certificate management cycle includes:

  • requests for certificate
  • issuance of certificate
  • revocation of certificate

When someone requests a certificate, the CA must take steps to verify that person is who they say they are. When the CA and the requester are friends, acquaintances or colleagues there are many ways to verify authentic identity.

Certificates can be used for several areas of internet communication including:

  1. Shell host access (through ssh protocol)
  2. Email server (through smtp, pop and imap protocols)
  3. Chat (through jabber and other chat protocols)
  4. Source Repository (through https, svn+ssh and other protocols)
  5. Web Intranet (through https)
  6. Message/file based signature and encryption
  7. Public Web

For the first five of these, an organization or community designated CA is clearly superior to the anonymous third-party certificate authority. However for a commercial website, the visitors to the site are often new or one-time customers. The expectation is that authentication and secure swapping of certificates will happen quickly. Third-party CA’s are ideal for these circumstances. While their verification and authentication procedures are minimal (usually verifying a domain name is linked to an IP address and that the requester is somehow associated with the domain name), it is usually enough to allow the sorts of transient communication necessary between a customer and a vendor, especially for the vast majority of the public. For message-based and file-based signature and encryption, the approach to certificates and certificate authorities depends on the situation. When the files and messages are passed among close colleagues, friends or family, again the third-party certificate authority is not as secure as a different mechanism organized among the participants. However, for a more anonymous passing of files — like from an online bank to a new customer — the third-party certificate authority again becomes useful.

DreamHost and Certificates

Currently, DreamHost requires purchase of a unique IP address for any use of SSL and public key certificates. However, this could change in the future. In theory, nothing about SSL and certificates requires a unique IP address. Though a static IP address is necessary for server based certificates. Without a static IP address, frequent changes of an IP address would require revocation of certificates and the issue of new replacement certificates every-time the server’s IP address changed.

External Links

Wikipedia has further reading on public key certificates and secure communication.