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.9.2. TLS_CAFile or Section 3.9.3. TLS_CAPath) and any certificate revocation list (CRL) for the certificate's issuer (see Section 3.9.14. TLS_CRLCheck and Section 3.9.16. TLS_CRLFile). If TLS_PolicyOID parameter 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 or,
  • 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 parameter 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 parameter 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
  • 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 parameter 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 parameter 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.