User`s guide

469
X.509 Certificates
In the previous section, security between two points was achieved by using a “pre-shared
secret” or password. Certificates provide this sort of mechanism but without the need to
manually enter or distribute secret keys. This is a complex area but put simply a user’s
certificate acts a little like a passport providing proof that the user is who they say they are
and enclosing details of how to use that certificate to decrypt data encoded with it.
Passports however can be forged so there also needs to be proof that the passport has been
properly issued and hasn’t been changed since it was. On a paper passport this is achieved
by covering the photograph with a coating that shows if it has been tampered with,
embedding the user’s name in code in a long string of numbers, etc. In the same way, for a
Security Certificate to be genuine it has to be protected from alteration as well. Like a
passport, you also have to trust that the issuer is authorized and competent to create the
certificate.
Certificates use something called a “Public/Private Key Pair”. This a complex area but the
principle is that you can create an encryption key made up from two parts, one private
(known only to the user), the other public (known to everyone). Messages encrypted with
someone’s public key can only be recovered by the person with the Public AND Private key
but as encrypting the message to someone in the first place only requires that you know
their public key, anyone who knows that can send them an encrypted message, so you can
send a secure message to someone knowing only their publicly available key. You can also
prove who you are by including in the message your “identity” whereupon they can look up
the certified public key for that identity and send a message back that only you can
understand. The important principles are that a) your private key cannot be determined
from your public key and b) you both need to be able to look up the others certified ID.
Once you’ve established a two way secure link you can use it to establish some rules for
further communication.
Before this gets any more complicated we’ll assume that Digi International are a competent
authority to issue certificates and given that they exist and are valid, see how they are
used.
Generally, the issuing and management of certificates will be provided as a managed
service by Digi or its partners, but some general information is provided here for system
administrators.
Certificates are held in non-volatile files on the unit. Any private files are named
privxxxx.xxx and cannot be copied, moved, renamed, uploaded or typed. This is to protect
the contents. They can be overwritten by another file, or deleted.
Two file formats for certificates are supported:
• PEM – Privacy Enhanced MIME
• DER – Distinguished Encoding Rules
Certificate and key files should be in one of these two formats, and should have an
extension of “.pem” or “.der” respectively.
Note:
The equivalent filename extension for .PEM files in Microsoft Windows is “.CER”. By
renaming “.PEM” certificate files to “.CER”, it is possible to view their makeup under
Windows.