Westermo MR Series - Manual (Page 387)

387 6622-3201
Web Interface and Command Line Reference Guide www.westermo.com
X.509 Certifi cates 13.5
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 dis tribute 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, embed ding 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 authorised 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 pub lic key and b) you both need to be able to look up the others certified
ID. Once you’ve established 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 Westermo 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
Westermo 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
can not be copied, moved, renamed, uploaded or typed. This is to protect the contents. They can be
over written 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.
The unit maintains two lists of certificate files. The first is a list of “Certificate Authorities” or CAs.
Files in this list are used to validate public certificates sent by remote users. Public certificates must
be signed by one of the certificates in the CA list before the unit can validate them. Certificates
with the filename CA*.PEM and CA*.DER are loaded into this list at start-up time. In the absence of
any CA certificates, a public certificate cannot be validated.
The second list is a list of public certificates that the unit can use to obtain public keys for decrypt-
ing signatures sent during IKE exchanges. Certificates with a filename CERT*.PEM and CERT*.DER
are loaded into this list when the unit is powered on or rebooted. Certificates in this list will be
used in cases where the remote unit does not send a certificate during IKE exchanges. If the list
does not contain a valid certificate communication with the remote unit cannot take place.
Both the host and remote units must have a copy of a file called CASAR.PEM. This file is required to
validate the certificates of the remote units.
In addition, the host unit should have copies of the files CERT02.PEM (which allows it to send this
cer tificate to remote units) and PRIVRSA.PEM. Note that before it can send this certificate, the
“Responder ID” parameter in the Configure > IPSEC > IKE page must be set to “host@Westermo.
co.uk”.