Wie viele Alternative Antragstellernamen (engl. Subject Alternative Name, SAN) unterstützen die Active Directory Certificate Services?

Autor Uwe GradeneggerVeröffentlicht am Kategorien Troubleshooting, Zertifizierungsstellen-DatenbankSchlagwörter , , , , , , ,

Wie jede Software unterliegen auch die Microsoft Active Directory Certificate Services bestimmten Grenzen, die durch ihr Design auferlegt sind.

Nicht so offensichtlich kann die Frage beantwortet werden, wie viele Alternative Antragstellernamen (engl. Subject Alternative Name, SAN) mit der Microsoft-Zertifizierungsstelle ausgestellt werden können.

Das IETF RFC 5280 beschreibt die Struktur für Subject Alternative Names wie folgt:

SubjectAltName ::= GeneralNames

GeneralNames sind hier definiert als:

GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

Im Appendix B., "ASN.1 Notes" findet sich letztendlich die Definition für eine SEQUENCE von der Größe "(1..MAX)":

The SIZE (1..MAX) construct constrains the sequence to have at least one entry.
MAX indicates that the upper bound is unspecified.
Implementations are free to choose an upper bound that suits their environment.

Somit gibt es nach RFC 5280 kein Limit für die Anzahl der Subject Alternative Names in der entsprechenden Zertifikaterweiterung, was theoretisch unendlich viele SANs zulässt. Doch wie verhält es sich nun mit der Microsoft-Zertifizierungsstelle?

Um dies herauszufinden, schreiben wir uns einen kleinen Test mit den PSCertificateEnrollment PowerShell Modul, welches wiederholt Zertifikate beantragt und dabei die Anzahl der alternativen Antragstellernamen schrittweise erhöht.

Import-Module PSCertificateEnrollment
1..1000 | ForEach-Object -Process { 
    $sans = @(1..$_ | % { "san-test-$_.intra.adcslabor.de" })
    New-CertificateRequest -Subject "CN=A Test" -Dns $sans | Get-IssuedCertificate -ConfigString "CA02.intra.adcslabor.de\ADCS Labor Issuing CA 1" -CertificateTemplate "ADCSLaborWebServer"
}

Dies geht eine Weile gut, doch auf einmal werden die Zertifikatanträge abgelehnt.

Das letzte erfolgreich ausgestellte Zertifikat beinhaltet in unserem Test 127 alternative Antragstellernamen.

Die Zertifizierungsstelle meldet für alle weiteren Zertifikatanforderungen mit mehr alternativen Antragstellernamen, dass eine Feldgröße überschritten sei.

Field length is greater than maximum 0xc80005e2 (ESE: -1506 JET_errColumnTooBig)

In der Ereignisanzeige finden wir das Ereignis mit ID 22 der Quelle Microsoft-Windows-CertificationAuthority mit gleichem Inhalt.

Wie sich zeigt ist die Zertifizierungsstelle nicht in der Lage, eine Datenbankzeile für den Zertifikatantrag zu erstellen, da die Feldgröße überschritten wurde.

Die Zertifikaterweiterungen werden in einem eigenen Feld in der Zertifizierungsstellen-Datenbank abgespeichert. Wie sich zeigt ist dieses Feld auf 4096 Byte beschränkt, was bei weiteren SANs überschritten wird.

certutil -schema Ext

Wir haben also unsere Frage falsch formuliert: Es gibt keine Beschränkung für die Anzahl der alternativen Antragstellernamen, jedoch für die Gesamt-Größe aller Zertifikaterweiterungen, von denen Subject Alternative Names eine von vielen anderen ist.

Dass in meinem Test genau 127 – eine in der IT-Welt andere Schlüssel nahelegende Zahl – SANs möglich waren, war mehr oder weniger Zufall. Die tatsächlich erreichbare Anzahl hängt von der Anzahl der Zeichen und weiterer Zertifikaterweiterungen im Zertifikatantrag ab, wie ein erneuter Test mit deutlich weniger Zeichen zeigt…

Dann speichere ich die Zertifikatanträge einfach nicht in der Datenbank

Von einem Leser habe ich die Anregung erhalten, dass es ja die Option gibt, die Zertifikatanträge nicht in der Zertifizierungsstellen-Datenbank zu speichern.

Diese Option ist in den meisten Fällen natürlich nicht sinnvoll, da entsprechende Zertifikate nicht zurückverfolgt und auch nicht widerrufen werden können.

Damit diese Option funktioniert, muss noch folgende globale Einstellung aktiviert werden:

certutil –setreg DBFlags +DBFLAGS_ENABLEVOLATILEREQUESTS

Nun sind noch einmal deutlich mehr SANs, respektive größere Zertifikaterweiterungen möglich, bevor wir letztendlich in die Limitierungen des MS-WCCE Protokolls laufen.

Das letzte erfolgreich ausgestellte Zertifikat ist ca. 90 Kilobyte groß.

Anmerkungen

Ich bin gespannt, ob die Limitierungen der Zertifizierungsstellen-Datenbank auch bei Aussagen zur künftig zu erwartenden Unterstützung von Post-Quanten-Kryptographie mit der Microsoft-Zertifizierungsstelle berücksichtigt wurden, da hier von deutlich größeren Zertifikaten ausgegangen werden kann.

Update: Feldgröße kann erhöht werden

Hans-Joachim Knobloch hat mich darauf hingewiesen, dass Microsoft zwischenzeitlich einen Artikel veröffentlicht hat, in dem beschrieben wird, wie das Datenbankfeld auf 16384 Byte vergrößert werden kann. Ebenso wird diese neue Möglichkeit in einem YouTube Video beschrieben.

Diese Möglichkeit kam für Windows Server Betriebssysteme ab Windows Server 2019 mit einem Patch im Jahr 2022:

certutil -setreg DBFlags +0x1000

Wie Microsoft im Artikel erwähnt, ist es nach Änderung des Datenbankschemas nicht mehr möglich, ältere Backups auf die Zertifizierungsstelle wiederherzustellen. Die Einstellung kann nicht rückgängig gemacht werden.

Nach einem Neustart des Zertifizierungsstellen-Dienstes sehen wir nun, dass die maximale Feldgröße nun bei 16384 KB liegt.

Ein erneuter Test klärt, ob wir nun erwartungsgemäß die vierfache Menge an SANs unterbringen können.

Doch wenn wir genau aufpassen, sehen wir dass 438 nicht die vierfache Menge von 127 ist. Wir sprengen nun nämlich die Grenze eines anderen Datenbankfeldes – die Gesamtgröße für das Zertifikat ist nämlich ebenfalls auf 16384KB beschränkt.

certutil -schema | findstr RawCertificate

Ein einfacher Export des letzten erfolgreich ausgestellten Zertifikats bestätigt unsere These.

Weiterführende Links:

Externe Quellen

de_DEDeutsch
en_USEnglish de_DEDeutsch