Add RFC 6125-compliant SAN support for client certificate identity extraction

[AntiD2ta]

Implement Subject Alternative Name (SAN) prioritization over the deprecated Common Name (CN) field for extracting client identities from certificates, ensuring compatibility with modern certificate authorities while maintaining backward compatibility with legacy CN-only certificates.

Changes:

• Implement SAN-first identity extraction with priority order:
  1. DNS names from SAN (RFC 6125 compliant)
  2. IP addresses from SAN (IPv4 and IPv6)
  3. Email addresses from SAN
  4. Common Name (CN) as fallback for legacy certificates
• Add comprehensive audit logging:
  • Log identity source (san-dns, san-ip, san-email, cn)
  • Log all SANs from certificate for security audit trail
  • Enhanced checker service logging with certificate details
• Add comprehensive test coverage
• Update documentation

This implementation ensures:

• RFC 6125 compliance for modern certificate standards
• Backward compatibility with existing CN-only certificates
• Support for modern CAs that issue SAN-only certificates
• Full audit trail of certificate identities for security analysis

Decisions required:

• Is the proposed priority order correct and desired? (we might want to extract and use DNS names only)
• Shall we go with a different approach? (Look at the Alternative approaches section below)
• Shall we support URI-based SANs (SPIFFE IDs, HTTPS URIs)?

These are intentionally not supported as they are uncommon in validator/signer architectures and would complicate the permission matching system without clear benefit.

• Shall we validate SAN values correctness?

Context:

✅ What Dirk Does Validate:

• Certificate signature and chain validity (via TLS)
• Certificate expiration (via TLS)
• Client certificate presence requirement
• Non-empty identity strings

❌ What Dirk Does NOT Validate:

• Email address format correctness
• IP address appropriateness for the context
• Domain ownership verification
• Identity-to-hostname matching

Alternative approaches:

Context: Proposed implementation only uses the first SAN entry, if cert has multiple SANs, others are ignored.

Multiple Identity Support

Allow a certificate to have multiple valid identities, check authorization against all of them.

Configurable Strategy

Let operators choose the behavior via configuration like:

certificates:
    identity-source: "san-preferred"  # Options: san-only, cn-only, san-preferred, cn-preferred, all
    san-types:                        # Which SAN types to consider
      - dns                           # DNS names
      # - email                       # Email addresses (if needed)
      # - uri                         # URIs (if needed)

Other???