CHEAT SHEET · X.509 / RFC 5280

rfc822Name — Subject Alternative Name

Der E-Mail-GeneralName in Zertifikaten: ASN.1-Form, OpenSSL-Rezepte, Validierungsregeln und die haeufigsten Verwechslungen mit dNSName.

Quelle: RFC 5280 §4.2.1.6 (GeneralName)
ASN.1-Tag: [1] IMPLICIT IA5String
Typischer Einsatz: S/MIME-Zertifikate, E-Mail-Signatur/-Verschluesselung

Was rfc822Name ist

GeneralName ist die CHOICE-Struktur hinter jedem Eintrag im subjectAltName-Extension-Feld. rfc822Name ist die Wahl mit Tag [1] und traegt eine einzelne E-Mail-Adresse als addr-spec (lokal@domain), ohne Anzeigename und ohne spitze Klammern. Der Werttyp ist IA5String — also reines 7-Bit-ASCII, keine Unicode-Lokalteile.

GeneralName — alle neun Varianten

Tag	Name	ASN.1-Typ	Typischer Gebrauch
[0]	otherName	OtherName	UPN, custom OIDs
[1]	rfc822Name	IA5String	E-Mail-Adresse (S/MIME)
[2]	dNSName	IA5String	Hostname (TLS-Server)
[3]	x400Address	ORAddress	X.400 (praktisch obsolet)
[4]	directoryName	Name	X.500 Distinguished Name
[5]	ediPartyName	EDIPartyName	EDI (praktisch obsolet)
[6]	uniformResourceIdentifier	IA5String	URI
[7]	iPAddress	OCTET STRING	IPv4/IPv6 (TLS-Server)
[8]	registeredID	OBJECT IDENTIFIER	OID als Identitaet

OpenSSL — setzen

openssl req -new -newkey rsa:2048 -nodes \
  -keyout smime.key -out smime.csr \
  -subj "/CN=Jane Doe" \
  -addext "subjectAltName=email:jane.doe@example.com"

# mehrere Mailboxen im selben Zertifikat:
-addext "subjectAltName=email:jane.doe@example.com,email:jane@example.org"

# Wert aus dem Subject-CN uebernehmen statt neu zu tippen:
-addext "subjectAltName=email:copy"

OpenSSL — pruefen

openssl x509 -in smime.pem -noout -text \
  | grep -A2 "Subject Alternative Name"

# nur die rfc822Name-Eintraege:
openssl x509 -in smime.pem -noout -ext subjectAltName \
  | grep -o 'email:[^, ]*'

Validierung (S/MIME Baseline Requirements)

Seit den CA/Browser-Forum-S/MIME-BRs (2023) braucht jede rfc822Name im oeffentlich vertrauenswuerdigen Zertifikat einen dokumentierten Nachweis, dass der Antragsteller die Mailbox kontrolliert — analog zur Domain-Validierung bei TLS, nur auf Mailbox-Ebene (z. B. Zufallswert per E-Mail an genau diese Adresse, oder Constructed-Email an die Authorization Domain Name).

Zertifikatstyp	rfc822Name erlaubt?	Bemerkung
S/MIME (Mailbox/Org/Sponsor-validiert)	JA	Pflichtfeld, mind. eine Mailbox
TLS-Server-Zertifikat	NEIN	CA/B-Forum-BR erlauben hier nur dNSName/iPAddress
Client-Auth (intern, private PKI)	JE NACH POLICY	Ausserhalb oeffentlichem Trust frei durch eigene CA-Policy

Haeufige Fallstricke

IA5String = ASCII-only. Internationalisierte Lokalteile oder Domains (Umlaute, Kyrillisch, ...) muessen ausserhalb von rfc822Name codiert werden (Punycode fuer die Domain) — ein direkter Unicode-Lokalteil ist im Feld selbst nicht darstellbar.
Kein Anzeigename. Nur addr-spec, also jane@example.com — nicht "Jane Doe" <jane@example.com>.
Verwechslung mit dNSName. rfc822Name validiert eine Mailbox, dNSName einen Hostnamen — unterschiedliche Validierungspfade, unterschiedliche Zertifikatsklassen.
Subject-CN ist nicht mehr autoritativ. Eine E-Mail-Adresse im CN des Subject-DN ist historisch verbreitet, aber moderne Clients und die S/MIME-BRs verlangen die SAN-Extension als massgebliche Quelle.
Kein Wildcard-Lokalteil. Jede Mailbox steht einzeln als eigener rfc822Name-Eintrag; ein Zertifikat kann aber mehrere davon gleichzeitig tragen.