Skip to main content

RFC 2818 - 3. Endpoint Identification

3. Endpoint Identification​

3.1. Server Identity​

Core Requirement: Clients MUST verify server identity to prevent man-in-the-middle attacks.

Identity Verification Process​

1. Client obtains hostname from URI
   e.g.: https://www.example.com

2. Server provides certificate in TLS handshake

3. Client checks if hostname matches certificate identity

Identity Field Priority​

Priority 1: subjectAltName (Subject Alternative Name)

subjectAltName extension in certificate (dNSName type):
dNSName: www.example.com
dNSName: api.example.com

← MUST use this field (if present) →

Priority 2: Common Name

CN in certificate Subject field:
CN=www.example.com

← Only use when no subjectAltName present →
← Deprecated, CAs should use dNSName →

Matching Rules​

1. Wildcard Matching:

Certificate: *.example.com
✅ Matches: foo.example.com
❌ Does not match: bar.foo.example.com

Certificate: f*.com
✅ Matches: foo.com
❌ Does not match: bar.com

2. IP Addresses:

URI: https://192.168.1.1/
Certificate must contain: iPAddress subjectAltName
Value must exactly match: 192.168.1.1

3. Multiple Identities:

If certificate contains multiple dNSName:
- www.example.com
- api.example.com
- *.app.example.com

← Matching any one is acceptable →

Behavior When No Match​

User-Oriented Clients (browsers):

  • ✅ MUST notify user
  • ⚠️ MAY give user option to continue
  • Or terminate connection

Automated Clients (API clients):

  • ✅ MUST log error to audit log
  • ✅ SHOULD terminate connection
  • ⚠️ MAY provide configuration option to disable check

Security Warning​

Untrusted URI Source:

Attack Scenario:
1. User clicks link in HTTP page
2. HTTP page itself is unencrypted
3. Man-in-the-middle may have replaced URI

Protection:
Users should carefully examine server certificate

3.2. Client Identity​

Typical Case: Server has no external knowledge of client identity.

If server has external knowledge (from outside HTTP or TLS):

  • Should check identity as described above

Client Certificate Authentication:

Common Scenarios:
- Internal enterprise systems
- API access control
- Mutual TLS (mTLS)

Verification:
- Certificate chain rooted in appropriate CA
- Optional: Verify specific client identity