256
6620-3201
12.5 X.509 Certifi cates
In the previous section, security between two points was achieved by using a “pre-shared secret”
or password. Certi
fi
cates 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 certi
fi
cate 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 certi
fi
cate 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 Certi
fi
cate 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 certi
fi
cate.
Certi
fi
cates 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
fi
rst 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 certi
fi
ed 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 certi
fi
ed 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
certi
fi
cates and given that they exist and are valid, see how they are used.
Generally, the issuing and management of certi
fi
cates will be provided as a managed service by
Westermo or it’s partners, but some general information is provided here for system administrators.
Certi
fi
cates are held in non-volatile
fi
les on the unit. Any private
fi
les 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
fi
le, or deleted.
Two
fi
le formats for certi
fi
cates are supported:
♦
PEM – Privacy Enhanced MIME
♦
DER – Distinguished Encoding Rules
Certi
fi
cate and key
fi
les should be in one of these two formats, and should have an extension of
“.pem” or “.der” respectively.
Note:
The equivalent
fi
lename extension for .PEM
fi
les in Microsoft Windows is “.CER”. By renaming “.PEM”
certi
fi
cate
fi
les to “.CER”, it is possible to view their makeup under Windows.
The unit maintains two lists of certi
fi
cate
fi
les. The
fi
rst is a list of “Certi
fi
cate Authorities” or CA’s. Files
in this list are used to validate public certi
fi
cates sent by remote users. Public certi
fi
cates must be
signed by one of the certi
fi
cates in the CA list before the unit can validate them. Certi
fi
cates with the
fi
lename CA*.PEM and CA*.DER are loaded into this list at start-up time. In the absence of any CA
certi
fi
cates, a public certi
fi
cate cannot be validated.
The second list is a list of public certi
fi
cates that the unit can use to obtain public keys for decrypting
signatures sent during IKE exchanges. Certi
fi
cates with a
fi
lename CERT*.PEM and CERT*.DER
are loaded into this list when the unit is powered on or rebooted. Certi
fi
cates in this list will be used
in cases where the remote unit does not send a certi
fi
cate during IKE exchanges. If the list does not
contain a valid certi
fi
cate communication with the remote unit cannot take place.
Both the host and remote units must have a copy of a
fi
le called CASAR.PEM. This
fi
le is required to
validate the certi
fi
cates of the remote units.
