Tunnels
73
Future FireBrick development will introduce TLS/HTTPS and when this is available private key upload will
be restricted to secure encrypted connections.
There are a number of different formats in use for holding certificates and private keys. The FireBrick accepts
standard DER-format (binary) and PEM-format (base64 armoured text) X.509 certificates, and DER-format
and unencrypted PEM-format private keys in raw or PKCS#8 form, as generated by utilities such as OpenSSL.
PKCS#7 and PKCS#12 format certificates and certificate bundles are not recognized by the FireBrick; these
should be split up into their component parts (eg using OpenSSL) before being uploaded to the FireBrick. Note
that private keys must not be encrypted (ie should not need a passphrase to access them). Again, OpenSSL
can be used to unencrypt and remove a passphrase from a private key before upload. When downloading a
certificate from the FireBrick, DER or PEM format can be selected.
For use with IPsec/IKEv2 end-entity certificates must hold an RSA or DSA public key. Currently the FireBrick
also only accepts RSA or DSA keys for CA certificates. This should not be a problem at present as the use
of newer style public keys in certificates used for signing other certificates is uncommon, and can always be
avoided if generating one's own CA certificatre.
As mentioned above, part of the authentication of a peer using a certificate consists of confirming that the
peer's IKE ID matches the ID recorded in the certificate. Certificates can hold identity information in more
than one way, and cryptographic implementations do not always agree on how the identity should be stored.
The FireBrick accepts the CommonName (CN) field of the Subject DistinguishedName for a KEYID-type ID,
or, for IP, FQDN or EMAIL type IDs, any SubjectAltName field of the right type. A certificate usually holds
some information regarding its purpose, and again there is not universal agreement among implementations
on how this usage information should be checked. The FireBrick requires a certificate to be used for IPsec
authentication to be marked as allowing use for digitalSignature or nonRepudiation, and a certificate to be used
for signing certificates must be marked as allowing use for certificate signature.
For a FireBrick IKE connection which authenticates itself to a peer using a certificate, it is necessary to install
a suitable end-entity certificate along with its associated private key on the FireBrick. Unless the certificate is
self-signed the certificate(s) used as CAs to provide a trust chain must also be installed, though private keys
are not required for these (and for security should not be installed). During the IKE authentication procedure
the FireBrick sends a copy of the certificate identifying itself to the peer, and also sends the trust chain of
certificate(s) used to sign the end-entity certificate. The peer does not need to have the end-entity certificate
installed, but must have a CA certificate (usually the self-signed "root" CA) installed so that it can check the
validity of the certificate. The private key for the CA certificate should be stored in a secure manner - not
on the FireBrick, and ideally not on any machine with a permanent network connection - a memory stick is
recommended. The CA certificate can have any suitable subject identity, and the end-entity certificate must
have a CN or SubjectAltName which corresponds with the local IKE identity which will be used for the
connection. For reliable interworking with other kit it is recommended that this is set using a FQDN (aka
DNS) subjectAltName field. The certificate which the FireBrick will use to authenticate itself to the peer can
be specified in the connection certlist item, using the short local name set when the certificate was installed.
This can normally be left unset, however, as the FireBrick will then choose a certificate which matches the
local-ID setting.
certlist, if set, should be the end-entity certificate identifying the local FireBrick, and peer-certlist, if set, should
be a list of the certificates which provide the trust for authenticating the peer's certificate. These can normally
be left unset, in which case the FireBrick will choose any suitable certificate matching the IKE local-ID for
authenticating itself, and any certificate(s) in the store for providing the trust of the peer's certificate.
A FireBrick connection which expects its peer to authenticate using a certificate needs to have either the end-
entity certificate or a CA certificate providing trust installed. If the peer-certlist item is not set, the FireBrick
will use any suitable certificate in its store to validate the peer's certificate; if set (to a list of short local names),
only those certificate(s) listed are acceptable.
Note that it is not obligatory to create and use a self-signed certificate. A large organization may have a master
CA which has been signed by a CA authority, and which is trusted automatically by many devices which have
a built-in set of root CAs. This master CA be used to sign a subsidiary CA, which is then used to sign the end-
entity certificate to be used for IKE authentication.
Содержание FB6402
Страница 1: ...FireBrick FB6402 User Manual FB6000 Versatile Network Appliance...
Страница 2: ......
