Authorize the peer

A valid certificate must still satisfy the selected local policy; failure aborts the handshake.

• Both endpoints MUST implement certification-path validation and end-entity certificate matching (§4.2.1). Path validation uses trust anchors and RFC 5280; exact certificate matching can use a self-signed certificate without a certification path. These are alternative validation methods, not consecutive checks required for every connection.
• Implementations MUST support authorized-peer fingerprints (§5.1). §4.2.2 hashes the DER-encoded certificate (its canonical binary representation), displays colon-separated uppercase hexadecimal bytes, and prefixes the algorithm label. Both endpoints MUST expose their certificate fingerprint through management. The 2009 text requires SHA-1 support (MUST) with label sha-1. Its published example is 65 characters; this records historical configuration support, not advice to choose SHA-1 for a new security design.
• For subject-name authorization (§5.2), implementations MUST support configured host names matched to dNSName in subjectAltName, SHOULD support common-name checking, and MUST support the stated certificate wildcard with an optional disable setting. A certificate *.example.com matches a.example.com but neither example.com nor a.b.example.com. Locally configured policy wildcards MAY be more flexible.
• Internationalized configured names MUST be converted to ACE for comparison; IP address matching in iPAddress is MAY (§5.2). These examples use ASCII DNS names only. §6.2 warns against obtaining the authorization name through a DNS lookup instead of local configuration.
• If the peer fails the selected security policy, the TLS handshake MUST be aborted with an appropriate TLS alert (§5). §§5.3–5.5 discuss one-sided or absent authentication; these policies are generally NOT RECOMMENDED because the corresponding masquerade threats remain. Properly authenticating and authorizing both peers is the RECOMMENDED default (§6.1).
• Both endpoints MUST provide key-pair and self-signed-certificate generation when no other mechanism supplies them, and SHOULD offer recording of end-entity certificates for correlation (§4.2.1). Pin provisioning and renewal are local administration; a received unknown fingerprint is not automatically trusted.