During the establishment of a TLS RadSec connection between a
RadSec client and RadSec server, certificate validation is performed in
order to confirm that they are connected to the peer they expect to be
connected to. This is a brief description of how validation is
performed.
In the RadSec server the client certificate
is examined. It is accepted if:
- The certificate contains a
subjectAltName
extension of type IPADDR that matches the client's IP address.
- There were no
subjectAltName
extensions, but
the certificate Subject contains a Common Name (CN) that matches the
client's IP address.
- The certificate Subject matches the
TLS_ExpectedPeerName
pattern.
and:
- If
TLS_SubjectAltNameURI
is defined in the
<ServerRADSEC>
clause, the certificate must
contain a subjectAltName
of type URI that matches
the TLS_SubjectAltNameURI
regular
expression.
- If
TLS_CertificateFingerprint
is defined in
the <ServerRADSEC>
clause, the
certificate's fingerprint must match at least one of the
TLS_CertificateFingerprint
options.
In the RadSec client, the server certificate is examined. It is
accepted if:
- The certificate contains a subjectAltName extension of type IPADDR
or DNS that matches the Host name used to connect to the server. If
TLS_SubjectAltNameDNS
is set, use its value to
match type DNS.
- There were no
subjectAltName
extensions, but
the certificate Subject contains a Common Name (CN) that matches the
Host name used to connect to the server.
- The certificate Subject matches the
TLS_ExpectedPeerName
pattern.
and:
- If
TLS_SubjectAltNameURI
is defined in the
<AuthBy RADSEC>
clause, the certificate
must contain a subjectAltName
of type URI that
matches the TLS_SubjectAltNameURI
regular
expression.
- If
TLS_CertificateFingerprint
is defined in
the <AuthBy RADSEC>
clause, the
certificate's fingerprint must match at least one of the
TLS_CertificateFingerprint
options.
TLS_SRVName
check passes, usually applicable
to <AuthBy RADSEC>
utilised by
<AuthBy DNSROAM>
.