Immer wieder – in der Regel alle Jahre oder zwei Jahre – laufen wichtige Zertifikate ab. Diese werden für wichtige Infrastrukturdienste wie zum Beispiel Exchange, Remotedesktop und anderes verwendet.
Leider haben sich – noch immer – nicht alle daran gewöhnt dass auch Microsoft vor „geraumer“ Zeit das DNS-Namensschema eingeführt hat, was dazu führt dass diese Dienste in der Regel nur mit dem internen Servernamen oder gar mit IP-Adressen anstatt des FQDN angesprochen werden. Dies führt dazu dass man immer dann wenn ein solches System ein Zertifikat benötigt es so anfertigen muss dass alle möglichen und unmöglichen Namens- und Zugriffsvarianten mit dem Zertifikat abgedeckt werden.
Hier kommt das SAN-Zertifikat, oder etwas präziser das Zertifikatsattribut „Subject Alternative Name“ zum tragen. Mit Hilfe dieses Attributes ist es möglich dass das Zertifikat nicht nur auf den primären Namen sondern auch noch auf eine Reihe alternativer Namen und IP-Adressen passt.
Da die Web-GUI des Windows PKI leider keine separaten Felder zur Angabe dieser alternativen Namen besitzt muss man das Attribut etwas kryptisch in das Feld „Attributr“ im Bereich „Zusätzliche Optionen“ eintragen.
Im Prinzip handelt es sich hierbei einfach um eine ASCII-Zeichenkette mit deren Hilfe alle möglichen Alternativen aufgelistet werden.
san:dns=Server1.intern.local&dns=Server1&ipaddress=192.168.0.1
Die Zeichenfolge beginnt mit dem Kürzel „san“ gefolgt von einem Doppelpunkt um zu Kennzeichnen dass mit diesem Eintrag das Attribut „Subject Alternative Name“ gemeint ist. Darauf folgend kommen nun die verschiedenen DNS-Namen oder IP-Adressen jeweils mit dem Kürzel „dns“ und „ipaddress“ gefolgt vom Gleichheitszeichen. Die einzelnen Varianten werden nun noch per Kaufmansund von einander getrennt.
Schickt man diese Anforderung mit dem angegebenen Attributsinformationen so ab bekommt man ein schönes, neues Zertifikat zurück mit den entsprechenden alternativen Namen.
Wie im Bild zu sehen heißt die deutschsprachige Bezeichnung dieses Attributes „Alternativer Antragstellername“ – eine etwas irreführende Bezeichnung wie ich finde.
Hat man die alternativen Namen klug und umsichtig gewählt kann man das Zertifikat nun im entsprechenden Server am entsprechenden Dienst verwenden und die Nutzer können den Dienst wie auch immer unter dem FQDN, über die IP-Adresse oder wie auch immer nutzen ohne dass es gleich wieder zu Problemen mit der Zertifikatsgültigkeit kommt.