16.1. RadSec Certificate Validation Previous topic Parent topic Child topic Next topic

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.
If a peer presents a certificate (TLS_RequireClientCert), then it is always validated using the peer certificate issuer's Root Certificate (see Section 3.11.2. TLS_CAFile or Section 3.11.3. TLS_CAPath) and any certificate revocation list (CRL) for the certificate's issuer (see Section 3.11.17. TLS_CRLCheck and Section 3.11.20. TLS_CRLFile). If TLS_PolicyOID is defined, the OIDs must be present in the certificate path. If that is successful, the contents of the peer certificate are checked:
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>.