Digi TransPort, Руководство пользователя

Страница: 393 / 813

About Internet Protocol Security (IPSec)
Digi TransPort User Guide 393
The router 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 router 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 router can use to obtain public keys for
decrypting signatures sent during IKE exchanges. Certificates with a filename cert*.pem and
cert*.der are loaded into this list when the router is powered on or rebooted. Certificates in
this list will be used in cases where the remote router 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
certificate to remote units) and privrsa.pem . Note that before it can send this certificate, the
Remote ID parameter in the Configuration > Network > Virtual Private Networking (VPN) >
IPsec > IPsec Tunnels > IPsec n - n > IPsec n page must be set to host@Digi.co.uk .
The remote unit must have copies of cert01.pem and privrsa.pem . In addition, any Eroutes that
are going to use certificates for authentication should be configured as follows:
Our ID
Should be set to info@Digi.co.uk . This is the same as the subject Altname in certificate
cert01.pem , which makes it possible for the router to locate the correct certificate to send to
the host.
Authentication Method
Should be set to RSA Signatures . This indicates to IKE that RSA signatures (certificates) are to
be used for authentication. When IKE receives a signature from a remote unit, it needs to be
able to retrieve the correct public key so that it can decrypt the signature, and confirm that the
signature is correct. The certificate must either be on the FLASH file system, or be provided by
the remote unit as part of the IKE negotiation. The ID provided by the remote unit is used to
find the correct certificate to use. If the correct certificate is found, the code then checks that it
has been signed by one of the certificate authority certificates ( ca*.pem ) that exist on the unit.
The code first checks the local certificates, and then the certificate provided by the remote (if
any). IKE will send a certificate during negotiations if it is able to find one that has subject
AltName that matches the ID being used. If not able to locate the certificate, then the remote
must have local access to the file so that the public key can be retrieved.
A typical setup may be that the host unit has a copy of all certificates. This means that the
remote units only require the private key, and the certificate authority certificate. This eases
administration as any changes to certificates need only be made on the host. Because they do
not have a copy of their certificate, remote units rely on the host having a copy of the
certificate. An alternative is that the remote units all have a copy of the certificate, as well as
the private key and certificate authority certificate, and the host only has its own certificate.
This scenario requires that the remote unit send its certificate during negotiations. It can
validate the certificate because it has the certificate authority certificate.