11: Security Settings
EDS1100/2100 Device Server User Guide
95
SSL Certificates
The goal of a certificate is to authenticate its sender. It is analogous to a paper document that
contains personal identification information and is signed by an authority, for example a notary or
government agency.
The principles of Security Certificate require that in order to sign other certificates, the authority
uses a private key. The published authority certificate contains the matching public key that allows
another to verify the signature but not recreate it.
The authority’s certificate can be signed by itself, resulting in a self-signed or trusted-root
certificate, or by another (higher) authority, resulting in an intermediate authority certificate. You
can build up a chain of intermediate authority certificates, and the last certification will always be a
trusted-root certificate.
An authority that signs other certificates is also called a Certificate Authority (CA). The last in line is
then the root-CA. VeriSign is a famous example of such a root-CA. Its certificate is often built into
web browsers to allow verifying the identity of website servers, which need to have certificates
signed by VeriSign or another public CA. Since obtaining a certificate signed by a CA that is
managed by another company can be expensive, it is possible to have your own CA. Tools exist to
generate self-signed CA certificates or to sign other certificates.
A certificate request is a certificate that has not been signed and only contains the identifying
information. Signing it makes it a certificate. A certificate is also used to sign any message
transmitted to the peer to identify the originator and prevent tampering while transported.
When using HTTPS, SSL Tunneling in Accept mode, and/or EAP-TLS, the EDS1100/2100 unit
needs a personal certificate with a matching private key to identify itself and sign its messages.
When using SSL Tunneling in Connect mode and/or EAP-TLS, EAP-TTLS or PEAP, the
EDS1100/2100 device server needs the authority certificate that can authenticate users with which
it wishes to communicate.
SSL RSA
As mentioned above, the certificates contain a public key. Different key exchange methods require
different public keys and therefore different certificate styles. The EDS1100/2100 device server
supports key exchange methods that require an RSA-style certificate. The RSA key exchange
method can work with this style if an RSA certificate is stored in the EDS1100/2100 unit.
The creation of a self-signed SSL certificate supports MD5 hash algorithms with a 1024 bit key
length. Uploading an SSL certificate will support MD5, SHA1 and SHA2 families (e.g., SHA256,
SHA384, and SHA512 hash algorithms with key lengths of 1024 & 2048 bits).
SSL Certificates and Private Keys
You can obtain a certificate by completing a certificate request and sending it to a certificate
authority that will create a certificate/key combo, usually for a fee, or you can generate your own. A
few utilities exist to generate self-signed certificates or sign certificate requests. The EDS1100/
2100 device server also has the ability to generate its own self-signed certificate/key combo.
You can use XML to export the certificate in PEM format, but you cannot export the key. Hence the
internal certificate generator can only be used for certificates that are to identify that particular
EDS1100/2100 unit.
Certificates and private keys can be stored in several file formats. Best known are PKCS12, DER
and PEM. Certificate and key can be in the same file or in separate files. The key can be encrypted
with a password or not. The EDS1100/2100 device server currently only accepts separate PEM
files. The key needs to be unencrypted.
