tls.verification

verification

The verification block defines custom certificate verification rules for TLS connections. Use this block to replace the standard certificate chain verification with custom logic, such as checking specific certificate fields, subject alternative names, or policy OIDs.

The verification block contains a pipeline that executes during the TLS handshake. The pipeline must end with either accept (allow connection) or reject (terminate connection). If the pipeline completes without an explicit accept or reject, the connection is rejected by default.

Important: When a verification block is present, it completely overrides the default certificate validation. The cert.valid variable indicates whether the standard certificate chain validation succeeded, but you must explicitly check it in your verification block. A verification block that only contains accept; would accept any certificate, including invalid, expired, or untrusted certificates.

Always check cert.valid first unless you have a specific reason to bypass standard validation.

Available Variables

The following cert namespace variables are available within the verification block:

Variable	Type	Description
`cert.valid`	boolean	Did standard certificate chain validation succeed?
`cert.error`	string	Verification error message (if validation failed)
`cert.server`	string	Server hostname (for client-side TLS verification)
`cert.issuer`	string	Certificate issuer distinguished name
`cert.subject`	string	Certificate subject distinguished name
`cert.serial`	number	Certificate serial number
`cert.issued`	timestamp	Certificate issue date
`cert.expires`	timestamp	Certificate expiry date
`cert.policy`	string array	Certificate policy OIDs
`cert.sha256`	bytes	SHA256 fingerprint of the certificate
`cert.issuer.*`	string array	Individual issuer name components (cn, o, ou, c, st, l, dc, emailaddress)
`cert.subject.*`	string array	Individual subject name components (cn, o, ou, c, st, l, dc, emailaddress)
`cert.subject_alt.*`	string array	Subject alternative names (email, dns, dn, uri, ip, oid, upn, other)
`cert.ca.*`	*	First CA certificate in the chain (same fields as cert.*)
`cert.ca[N].*`	*	Nth CA certificate in the chain

Example: Certificate Policy Verification

Require certificates issued under a specific certificate policy OID (common in enterprise PKI deployments where different certificate templates have different policy OIDs):

tls {
    certificate "SERVER_CERT";
    certificate_key "SERVER_KEY";
    server_ca_certificate "CA_CERT";
    require_client_certificate true;
    client_ca_certificate "CLIENT_CA";

    verification {
        if any {
            # Always check certificate chain validity first
            cert.valid != true;
            # Require network device certificate policy
            cert.policy != "1.3.6.1.4.1.99999.1.2.3";
        } then {
            reject;
        } else {
            accept;
        }
    }
}

Example: Hostname Verification Override

When connecting to a server by IP address but the certificate contains a hostname. Note that cert.valid is checked first to ensure the certificate chain is valid:

connect {
    protocol tls;
    host "127.0.0.1";
    port 2083;

    tls {
        certificate "CLIENT_CERT";
        certificate_key "CLIENT_KEY";
        server_ca_certificate "SERVER_CA";

        verification {
            if any {
                # Always check certificate chain validity first
                cert.valid != true;
                # Then verify the expected hostname
                cert.subject_alt.dns != "radius.example.com";
            } then {
                reject;
            } else {
                accept;
            }
        }
    }
}

Example: Subject Alternative Name Validation

Verify the certificate contains an expected DNS name or email:

verification {
    if any {
        # Always check certificate chain validity first
        cert.valid != true;
        # Require certificate for wifi devices subdomain
        cert.subject_alt.dns !ends ".wifi.devices.example.com";
    } then {
        reject;
    } else {
        accept;
    }
}

Example: Certificate Field Validation

Reject certificates from specific issuers or with specific subject fields:

verification {
    if any {
        # Always check certificate chain validity first
        cert.valid != true;
        # Reject test certificates
        cert.subject_alt.email starts "test";
        # Require specific organization
        cert.subject.o != "Example Corp";
    } then {
        reject;
    } else {
        accept;
    }
}

Example: EAP-TLS Client Certificate Verification

Custom verification for EAP-TLS client certificates:

eap-tls {
    certificate "EAP_SERVER_CERT";
    certificate_key "EAP_SERVER_KEY";
    client_ca_certificate "EAP_CLIENT_CA";

    verification {
        if any {
        # Always check certificate chain validity first
            cert.valid != true;
            # Reject certificates with test email addresses
            cert.subject_alt.email starts "test";
        } then {
            reject;
        } else {
            accept;
        }
    }
}

Context-Specific Usage

The verification block can be used in multiple TLS contexts:

Context	Description
`servers.*.listen.tls.verification`	Server-side client certificate verification
`backends.radius.server.connect.tls.verification`	RadSec proxy server certificate verification
`aaa.policy.handler.*.eap-tls.verification`	EAP-TLS client certificate verification
`aaa.policy.handler.*.eap-ttls.verification`	EAP-TTLS client certificate verification
`aaa.policy.handler.*.eap-peap.verification`	EAP-PEAP client certificate verification