VPN-Zertifikatsinventar: Was das CA-Register beweisen kann
Ein Serverordner, ein CA-Register, eine Sperrliste und eine Sitzungstabelle beantworten verschiedene Fragen. Halten Sie sie getrennt, wenn Sie VPN-Identitäten inventarisieren.
Ihr Gateway akzeptiert ein Clientzertifikat, das es nie gesehen hat, weil das, womit es konfiguriert wurde, ein vertrauenswürdiger Aussteller ist und das Zertifikat während des Handshakes eintrifft. So soll das Protokoll funktionieren, und deshalb ist eine Verzeichnisauflistung auf dem Server ein schlechtes Inventar. Der Aussteller weiß, was er erstellt hat, der Server weiß, was sich verbunden hat, und der Sperrstatus weiß, was zurückgezogen wurde. Ein Inventar, das diese drei Aufzeichnungen vermischt, behauptet am Ende etwas, das keine von ihnen gesagt hat.
Das Gateway vertraut einem Aussteller, nicht einer Dateiliste
Die Validierung vergleicht ein vorgelegtes Zertifikat mit einem Vertrauensanker, sodass eine Identität, die derselbe Aussteller gestern erstellt hat, sich verbindet, ohne jemals auf der Festplatte des Servers existiert zu haben. Dafür muss nichts kopiert werden, und niemand muss es von Hand genehmigen. Die eigenen Aufzeichnungen des Servers beschreiben daher Ankünfte, nicht die Grundgesamtheit der Identitäten, die ankommen könnten.
Die umgekehrte Lücke ist genauso unangenehm. Ein Verzeichnis kann abgelaufene Zertifikate, gesperrte und Identitäten enthalten, die für nie bereitgestellte Geräte ausgestellt wurden. Dateien zu zählen beantwortet, wie viele Dateien vorhanden sind, was eine Frage ist, die niemand gestellt hat. Beginnen Sie stattdessen bei den Aufzeichnungen, die Bedeutung tragen.
Vier Fragen, vier verschiedene Register
Jeder Aufzeichnungstyp beantwortet eine Frage gut und die übrigen schlecht, weshalb ein Bericht, der sie zusammenführt, vollständig wirkt, während er auf eine bestimmte Weise falsch ist. Die folgende Tabelle ordnet sie nach der Frage, die sie klären, und nicht nach dem System, das sie erzeugt.
| Question you are answering | Where the answer lives | How quickly it changes | What it will never show |
|---|---|---|---|
| Was this identity ever created? | The issuer's issuance database | Only when something is issued | Whether the device still exists |
| Is a copy sitting on this host? | The paths you actually inspected | Whenever anyone copies files | Certificates that were never copied here |
| Has the issuer withdrawn it? | Published revocation state | When the issuer next publishes | Withdrawals that are not published yet |
| Is it connected right now? | The live session table | Continuously | Anything about past or future sessions |
Ein Archiv öffentlicher Zertifikate ist kein Geheimnis, da es keine privaten Schlüssel enthält, aber es ist auch nicht teilbar. Subjekte und Gerätenamen verraten betriebliche Details, und der Bericht sollte bei dem Publikum bleiben, das ihn braucht. Private Schlüssel bleiben ganz außerhalb des Inventars, weil das Inventar Metadaten braucht und keine Anmeldeinformationen.
Aussteller plus Seriennummer ist der einzige stabile Schlüssel
Subjekte werden wiederverwendet und Dateinamen erneut genutzt, sodass ein Name, der letztes Jahr ein Gerät bezeichnete, heute ein anderes bezeichnen kann. Keines von beiden ist ein Schlüssel, und ein Bericht, der auf einem von ihnen aufbaut, wird am Ende zwei Identitäten in einer Zeile zusammenführen.
Das Paar aus Aussteller und Seriennummer identifiziert ein Zertifikat eindeutig, und beide Felder stammen aus dem Zertifikat selbst. Erfassen Sie sie zusammen mit dem Subjekt, den Gültigkeitsdaten, der Quelle, aus der die Kopie stammt, und der verantwortlichen Person oder dem Gerät. Fügen Sie Sperr- und Bereitstellungsstatus als getrennte Felder mit eigenen Beobachtungszeiten hinzu, denn ein Zertifikat innerhalb seines Gültigkeitsfensters ist nicht automatisch autorisiert. Diese beiden Tatsachen leben in verschiedenen Systemen, und ihr Zusammenlegen verbirgt den Fall, in dem eine Identität zurückgezogen wurde, während ihre Datei noch aktuell aussieht.
Lesen Sie jeweils ein Zertifikat
Ein Platzhalter, der sich über ein Verzeichnis erstreckt, ist keine Stapelschnittstelle und verbirgt, welche Datei welche Ausgabe erzeugt hat. Lesen Sie die Metadaten je Zertifikat und lesen Sie die Sperrseite aus ihrem eigenen Artefakt. Die OpenSSL-x509-Referenz listet die Felder auf, die diese Optionen ausgeben.
openssl x509 -in <cert>.pem -noout -issuer -serial -subject -dates -fingerprint -sha256
openssl crl -in <issuer>.crl -noout -text | head -n 40Fragen Sie bei einer verwalteten Easy-RSA-PKI die Ausstellungsdatenbank über den vom Werkzeug unterstützten Arbeitsablauf ab, anstatt ein Verzeichnislayout anzunehmen, und halten Sie die Originale schreibgeschützt, während das Inventar zusammengestellt wird. Das Registerformat ist regelmäßig genug, um gültige Einträge zu zählen und die zurückgezogenen aufzulisten, ohne die Datenbank von Hand zu öffnen.
grep -c '^V' pki/index.txt
grep '^R' pki/index.txt | cut -f4,5Ein Inventar, das die nächste Ausstellung übersteht
Ein einmaliger Verzeichnisauszug ist in dem Moment veraltet, in dem das nächste Zertifikat ausgestellt wird, bauen Sie den Bericht daher aus dem Ausstellungsablauf und lassen Sie ihn als Teil des normalen Betriebs aktualisieren. Das macht den Bericht auch reproduzierbar, was zählt, wenn zwei Personen uneinig sind, was ausgestellt wurde.
Verwenden Sie das Ergebnis für Entscheidungen zu Verlängerung und Außerbetriebnahme statt als Tabellenkalkulationsübung. Das Löschen einer lokalen Kopie macht die bereits vorhandenen entfernten Kopien nicht ungültig. Ziehen Sie die Identität über den konfigurierten Sperr- und Autorisierungsablauf zurück und erfassen Sie die Rücknahme mit ihrem Datum. Eine Identität, die vom Server verschwunden ist, der der Aussteller aber weiterhin vertraut, ist nicht außer Betrieb genommen, und genau dieser Unterschied trennt ein genaues Inventar von einem, das nur beruhigt.