Ssl certificates, Ssl rsa or dsa – Lantronix XPort AR User Manual
Page 89

10: Security Settings
XPort AR User Guide
89
Whichever side is acting as server decides which cipher suite to use for a connection. It is usually
the strongest common denominator of the cipher suite lists supported by both sides.
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 required 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 another 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 XPort AR 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 XPort AR needs the
authority certificate that can authenticate users with which it wishes to communicate.
SSL RSA or DSA
As mentioned above, the certificates contain a public key. Different key exchange methods require
different public keys and thus different styles of certificate. The XPort AR supports key exchange
methods that require a RSA-style certificate and key exchange methods that require a DSA-style
certificate. If only one of these certificates is stored in the XPort AR, only those key exchange
methods that can work with that style certificate are enabled. RSA is sufficient in most cases.
RSA
RSA
128 bits RC4
SHA1
RSA
1024 bits RSA
56 bits RC4
MD5
RSA
1024 bits RSA
56 bits RC4
SHA1
RSA
1024 bits RSA
40 bits RC4
MD5
Table 10-5 Supported Cipher Suites (continued)
Certificate
Key Exchange
Encryption
Hash