In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
Dieses Dokument beschreibt ausführlich die Zertifikatsweiterleitung auf Cisco IOS Public Key Infrastructure (PKI)-Servern und -Clients.
Für dieses Dokument bestehen keine speziellen Anforderungen.
Die Informationen in diesem Dokument basieren auf den folgenden Hardware- und Softwareversionen:
Hinweis: Die allgemeine Softwarewartung für ISR-Geräte ist nicht mehr aktiv. Für künftige Bugfixes oder Funktionsverbesserungen ist ein Hardware-Upgrade auf ISR-2- oder ISR-4xxx-Router erforderlich.
Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.
Durch das Rollover von Zertifikaten, auch als Verlängerungsvorgang bezeichnet, wird sichergestellt, dass ein neues Zertifikat nach Ablauf eines Zertifikats übernommen werden kann. Aus Sicht eines PKI-Servers bedeutet dieser Vorgang, dass das neue Server-Rollover-Zertifikat rechtzeitig im Voraus generiert wird, um sicherzustellen, dass alle PKI-Clients ein neues Client-Rollover-Zertifikat erhalten haben, das vom neuen Server-Rollover-Zertifikat signiert wurde, bevor das aktuelle Zertifikat abläuft. Wenn das Clientzertifikat abläuft, das Zertifikat des CA-Servers aber nicht, fordert der Client ein neues Zertifikat an und ersetzt das alte Zertifikat, sobald das neue Zertifikat eingegangen ist. Wenn das Clientzertifikat gleichzeitig mit dem Zertifikat des CA-Servers abläuft, stellt der Client sicher, dass er zuerst das Rollover-Zertifikat des CA-Servers erhält und fordert dann einen Rollover an Zertifikat, das vom neuen CA-Server-Rollover-Zertifikat signiert wurde, und beide werden aktiviert, wenn alte Zertifikate ablaufen.
In IOS gilt die Taktquelle standardmäßig als nicht autoritär, da die Hardware-Uhr nicht die beste Zeitquelle ist. Da PKI zeitabhängig ist, ist es wichtig, eine gültige Zeitquelle mithilfe von NTP zu konfigurieren. Bei einer PKI-Bereitstellung wird empfohlen, dass alle Clients und der Server ihre Uhr mit einem einzigen NTP-Server synchronisieren, gegebenenfalls über mehrere NTP-Server. Weitere Informationen hierzu finden Sie im IOS PKI Deployment Guide: Erstmaliges Design und erstmalige Bereitstellung
IOS initialisiert PKI-Timer nicht ohne eine autoritative Uhr. Obwohl NTP dringend empfohlen wird, kann der Administrator die Hardware-Uhr als temporäre Maßnahme wie folgt als autoritär markieren:
Router(config)# clock calendar-valid
Eine Voraussetzung für einen aktiven IOS-PKI-Server ist der HTTP-Server, der mithilfe des folgenden Befehls auf Konfigurationsebene aktiviert werden kann:
ip http server <1024-65535>
Dieser Befehl aktiviert standardmäßig den HTTP-Server an Port 80, der wie oben gezeigt geändert werden kann.
PKI-Clients sollten über HTTP mit dem PKI-Server kommunizieren können.
Die automatische Rollover-Konfiguration des PKI-Servers sieht wie folgt aus:
crypto pki server ROOTCA
database level complete
database archive pkcs12 password 7 01100F175804575D72
issuer-name CN=RootCA,OU=TAC,O=Cisco
grant auto
lifetime certificate 365
lifetime ca-certificate 730
database url ftp://10.1.1.1/DB/ROOTCA/
auto-rollover 90
Der Parameter für die automatische Rollover-Funktion wird in Tagen definiert. Auf detaillierterer Ebene sieht der Befehl wie folgt aus:
auto-rollover <days> <hours> <minutes>
Ein Auto-Rollover-Wert von 90 gibt an, dass das IOS 90 Tage vor Ablauf des aktuellen Serverzertifikats ein Rollover-Server-Zertifikat erstellt. Die Gültigkeit dieses neuen Rollover-Zertifikats beginnt mit dem Ablaufdatum des aktuellen aktiven Zertifikats.
Auto-Rollover sollte mit einem solchen Wert konfiguriert werden, der sicherstellt, dass das Rollover-CA-Zertifikat lange im Voraus auf dem PKI-Server generiert wird, bevor ein PKI-Client im Netzwerk GetNextCACert-Vorgang ausführt, wie im Abschnitt SHADOW-Vorgangsübersicht beschrieben.
Die Konfiguration der automatischen Zertifikatsverlängerung für den PKI-Client sieht wie folgt aus:
crypto pki trustpoint Root-CA
enrollment url http://172.16.1.1:80
serial-number
ip-address none
password 0 Rev0cati0n$Passw0rd
subject-name CN=spoke-1.cisco.com,OU=CVO
revocation-check crl
rsakeypair spoke-1-RSA
auto-enroll 80
Hier gibt der Befehl auto-enroll <percentage> [regenerate] an, dass das IOS eine Zertifikatsverlängerung mit genau 80 % der Lebensdauer des aktuellen Zertifikats durchführen soll.
Das Schlüsselwort regenerate gibt an, dass IOS das RSA-Schlüsselpaar, das Schattenschlüsselpaar, bei jedem Verlängerungsvorgang für Zertifikate neu generieren soll.
Bei der Konfiguration des Prozentsatzes für die automatische Anmeldung ist darauf zu achten. Wenn bei einem bestimmten PKI-Client in der Bereitstellung eine Bedingung auftritt, bei der das Identitätszertifikat gleichzeitig mit dem ausstellenden Zertifizierungsstellenzertifikat abläuft, sollte der Wert für die automatische Registrierung immer den [Schatten] Verlängerungsvorgang auslösen, nachdem die Zertifizierungsstelle das Rollover-Zertifikat erstellt hat. In den Bereitstellungsbeispielen finden Sie im Abschnitt Abhängigkeiten des PKI-Timers weitere Informationen.
In diesem Dokument werden die Vorgänge für das Rollover und die Verlängerung von Zertifikaten detailliert beschrieben. Daher werden diese Ereignisse als erfolgreich angesehen:
Die Registrierung eines Clients umfasst diese Ereignisse. Ohne zu viel ins Detail zu gehen:
In IOS ist ein Trustpoint ein Container für Zertifikate. Jeder Trustpoint kann ein aktives Identitätszertifikat und/oder ein aktives Zertifizierungsstellen-Zertifikat enthalten. Ein Trustpoint gilt als authentifiziert, wenn er ein aktives CA-Zertifikat enthält. Sie gilt als registriert, wenn sie ein Identitätszertifikat enthält. Ein Trustpoint muss vor der Registrierung authentifiziert werden. Die Konfiguration von PKI-Servern und -Clients sowie die Authentifizierung und Registrierung von Vertrauenspunkten werden im IOS PKI Deployment Guide detailliert beschrieben: Erstmaliges Design und erstmalige Bereitstellung
Nach dem Abruf/der Installation des Zertifizierungsstellenzertifikats ruft der PKI-Client die PKI-Serverfunktionen ab, bevor er eine Registrierung durchführt. Der Abruf von CA-Funktionen wird in diesem Abschnitt erläutert.
Wenn in IOS ein PKI-Client eine CA authentifiziert, d. h. wenn ein Administrator einen Vertrauenspunkt auf einem IOS-Router erstellt und den Befehl crypto pki authentifiziert <trustpoint-name>, finden diese Ereignisse auf dem Router statt:
Die Antwort wird vom IOS PKI-Client folgendermaßen interpretiert:
CA_CAP_GET_NEXT_CA_CERT
CA_CAP_RENEWAL
CA_CAP_SHA_1
CA_CAP_SHA_256
Im Mittelpunkt dieses Dokuments stehen diese beiden Funktionen.
Wenn diese Funktion von der CA zurückgegeben wird, versteht IOS, dass die CA Rollover von CA-Zertifikaten unterstützt. Wenn diese Funktion zurückgegeben wird und der Befehl zur automatischen Registrierung nicht unter dem Vertrauenspunkt konfiguriert ist, initialisiert IOS einen SHADOW-Timer, der auf 90 % der Gültigkeitsdauer des Zertifizierungsstellenzertifikats festgelegt ist.
Wenn der SHADOW-Timer abläuft, führt IOS einen GetNextCACert-SCEP-Vorgang aus, um das Zertifikat der Rollover-Zertifizierungsstelle abzurufen.
Hinweis: Wenn der Befehl zur automatischen Registrierung unter dem Vertrauenspunkt zusammen mit einer Registrierungs-URL konfiguriert wurde, wird ein RENEW-Timer bereits vor der Authentifizierung des Vertrauenspunkts initialisiert. Er versucht ständig, sich bei der CA in der Registrierungs-URL anzumelden, obwohl bis die Authentifizierung des Vertrauenspunkts abgeschlossen ist, keine tatsächliche Registrierungsnachricht [CSR] gesendet wird.
Hinweis: GetNextCACert wird vom IOS PKI-Server als Funktion gesendet, selbst wenn der automatische Rollover auf dem Server nicht konfiguriert ist.
Mit dieser Funktion informiert der PKI-Server den PKI-Client, dass er ein aktives ID-Zertifikat verwenden kann, um eine Zertifikatssignierungsanfrage zu unterzeichnen, um das vorhandene Zertifikat zu erneuern.
Weitere Informationen hierzu finden Sie im Abschnitt PKI Client Auto-Renewal.
Bei der obigen Konfiguration auf dem CA-Server sehen Sie:
Root-CA#show crypto pki certificates
CA Certificate
Status: Available
Certificate Serial Number (hex): 01
Certificate Usage: Signature
Issuer:
cn=RootCA
ou=TAC
o=Cisco
Subject:
cn=RootCA
ou=TAC
o=Cisco
Validity Date:
start date: 13:14:16 CET Oct 9 2015
end date: 13:14:16 CET Oct 8 2017
Associated Trustpoints: ROOTCA
Root-CA#terminal exec prompt timestamp
Root-CA#show crypto pki timers
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
Time source is NTP, 13:19:58.946 CET Fri Oct 9 2015
PKI Timers
| 7:49.003
| 7:49.003 SESSION CLEANUP
| 3d 7:05:24.003 TRUSTPOOL
CS Timers
| 5:54:17.977
| 5:54:17.977 CS CRL UPDATE
|639d23:54:17.977 CS SHADOW CERT GENERATION
|729d23:54:17.971 CS CERT EXPIRE
Beachten Sie Folgendes:
Wenn der Zeitgeber CS SHADOW CERT GENERATION abläuft:
Jul 10 13:14:16.510: CRYPTO_CS: shadow generation timer fired.
Jul 10 13:14:16.510: CRYPTO_CS: key 'ROOTCA#' does not exist; generated automatically
Root-CA# show crypto key mypubkey rsa
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
Time source is NTP, 13:19:19.652 CET Mon Jul 10 2017
% Key pair was generated at: 13:14:16 CET Oct 9 2015
Key name: ROOTCA
Key type: RSA KEYS
Storage Device: private-config
Usage: General Purpose Key
Key is not exportable.
Key Data:
30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00B07127
360CF006 13B259CE 7BB8158D E6BC8AA4 8A763F73 50CE64B0 71AC5D93 ED59C936
F751D810 70CEA8C8 B0023B4B 0FB9A538 A1C118D3 5530D46D C4B4DC14 3BD1D231
48B0C053 A781D0C7 86DEE9DE CCA58C18 B5804B29 911D1D57 76B3EC3F 42D38C3A
1E0F8DD9 1DE228B9 95AC3C10 87C132FC 75956338 258727F6 1A1F0818 83020301 0001
% Key pair was generated at: 13:14:18 CET Jul 10 2017
Key name: ROOTCA#
Key type: RSA KEYS
Storage Device: not specified
Usage: General Purpose Key
Key is not exportable.
Key Data:
30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00BF2A52
687F112B C9263541 BB402939 9C66D270 8D3EACED 4F63AA50 9FB340E8 38C8AC38
1818EA43 93C17CA1 C4917F43 C9199C9E F9F9C059 FDE11DA9 C7991826 43736FCE
A80D0CEE 2378F23B 6AC5FC3B 4A7A0120 D391BE8F A9AFD212 E05A2864 6610233C
E0E58D93 23AA0ED2 A5B1C140 122E6E3D 98A7D974 E2363902 70A89CE3 BF020301 0001
Jul 10 13:14:18.326: CRYPTO_CS: shadow CA successfully created.
Jul 10 13:14:18.326: CRYPTO_CS: exporting shadow CA key and cert
Jul 10 13:14:18.327: CRYPTO_CS: file opened: ftp://10.1.1.1/DB/ROOTCA/ROOTCA_00001.p12
Root-CA# show crypto pki certificates
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
Time source is NTP, 13:14:46.820 CET Mon Jul 10 2017
CA Certificate (Rollover)
Status: Available
Certificate Serial Number (hex): 03
Certificate Usage: Signature
Issuer:
cn=RootCA
ou=TAC
o=Cisco
Subject:
Name: RootCA
cn=RootCA
ou=TAC
o=Cisco
Validity Date:
start date: 13:14:16 CET Oct 8 2017
end date: 13:14:16 CET Oct 8 2019
Associated Trustpoints: ROOTCA
CA Certificate
Status: Available
Certificate Serial Number (hex): 01
Certificate Usage: Signature
Issuer:
cn=RootCA
ou=TAC
o=Cisco
Subject:
cn=RootCA
ou=TAC
o=Cisco
Validity Date:
start date: 13:14:16 CET Oct 9 2015
end date: 13:14:16 CET Oct 8 2017
Associated Trustpoints: ROOTCA
Storage: nvram:RootCA#1CA.cer
Root-CA# show crypto pki server
Certificate Server ROOTCA:
Status: enabled
State: enabled
Server's configuration is locked (enter "shut" to unlock it)
Issuer name: CN=RootCA,OU=TAC,O=Cisco
CA cert fingerprint: CC748544 A0AB7832 935D8CD0 214A152E
Granting mode is: manual
Last certificate issued serial number (hex): 6
CA certificate expiration timer: 13:14:16 CET Oct 8 2017
CRL NextUpdate timer: 19:11:54 CET Jul 10 2017
Current primary storage dir: unix:/iosca-root/
Database Level: Complete - all issued certs written as <serialnum>.cer
Rollover status: available for rollover
Rollover CA certificate fingerprint: 031904DC F4FAD1FD 8A866373 C63CE20F
Rollover CA certificate expiration time: 13:14:16 CET Oct 8 2019
Auto-Rollover configured, overlap period 90 days
Root-CA# show run | section chain ROOTCA
crypto pki certificate chain ROOTCA
certificate ca rollover 03
30820237 308201A0 A0030201 02020103 300D0609 2A864886 F70D0101 04050030
2F310E30 0C060355 040A1305 43697363 6F310C30 0A060355 040B1303 54414331
0F300D06 03550403 1306526F 6F744341 301E170D 31373130 30383132 31343136
5A170D31 39313030 38313231 3431365A 302F310E 300C0603 55040A13 05436973
636F310C 300A0603 55040B13 03544143 310F300D 06035504 03130652 6F6F7443
4130819F 300D0609 2A864886 F70D0101 01050003 818D0030 81890281 8100BF2A
52687F11 2BC92635 41BB4029 399C66D2 708D3EAC ED4F63AA 509FB340 E838C8AC
381818EA 4393C17C A1C4917F 43C9199C 9EF9F9C0 59FDE11D A9C79918 2643736F
CEA80D0C EE2378F2 3B6AC5FC 3B4A7A01 20D391BE 8FA9AFD2 12E05A28 64661023
3CE0E58D 9323AA0E D2A5B1C1 40122E6E 3D98A7D9 74E23639 0270A89C E3BF0203
010001A3 63306130 0F060355 1D130101 FF040530 030101FF 300E0603 551D0F01
01FF0404 03020186 301F0603 551D2304 18301680 1419FCA4 DDE84233 F79C066F
93CCF6B3 E14F8355 31301D06 03551D0E 04160414 19FCA4DD E84233F7 9C066F93
CCF6B3E1 4F835531 300D0609 2A864886 F70D0101 04050003 81810065 AC780BB4
2398D765 BE4C4C0A 0D0F16C0 82530D85 99933BDC 8388C46D 926145D8 B0BA275A
93AAB497 FC876F6A E951C138 F5D652AE C0C25E2A FDD80BAA C6BD5A78 E439158F
5544F30F 33C59E22 1994A8D3 AADC1287 BD15A104 55CB5DC3 49A9401A 8DB3940A
5054EA21 99CCE4F3 40B471FE DEB4BB38 AC3ACD48 4CDDCBC9 9829D3
quit
certificate ca 01
30820237 308201A0 A0030201 02020101 300D0609 2A864886 F70D0101 04050030
2F310E30 0C060355 040A1305 43697363 6F310C30 0A060355 040B1303 54414331
0F300D06 03550403 1306526F 6F744341 301E170D 31353130 30393132 31343136
5A170D31 37313030 38313231 3431365A 302F310E 300C0603 55040A13 05436973
636F310C 300A0603 55040B13 03544143 310F300D 06035504 03130652 6F6F7443
4130819F 300D0609 2A864886 F70D0101 01050003 818D0030 81890281 8100B071
27360CF0 0613B259 CE7BB815 8DE6BC8A A48A763F 7350CE64 B071AC5D 93ED59C9
36F751D8 1070CEA8 C8B0023B 4B0FB9A5 38A1C118 D35530D4 6DC4B4DC 143BD1D2
3148B0C0 53A781D0 C786DEE9 DECCA58C 18B5804B 29911D1D 5776B3EC 3F42D38C
3A1E0F8D D91DE228 B995AC3C 1087C132 FC759563 38258727 F61A1F08 18830203
010001A3 63306130 0F060355 1D130101 FF040530 030101FF 300E0603 551D0F01
01FF0404 03020186 301F0603 551D2304 18301680 148D421A BED6DCAD B8CFE4B4
1B2C7E41 C73428AC 9A301D06 03551D0E 04160414 8D421ABE D6DCADB8 CFE4B41B
2C7E41C7 3428AC9A 300D0609 2A864886 F70D0101 04050003 8181008C 3495278E
DA6C14B0 533E746D 8DA743AF 06BE4088 913BF9BC A94576FA BC86EFD1 1DFE6B9F
0D244144 473C67AD 24414A20 84E9B083 D1720766 0A698C29 115482C6 2FB57E86
95CDECF2 29662362 866CDC91 730ADBB3 BDBBDC3C EA5301B0 150658E7 AF722BD7
6B5C2D6A 661A4FED CDA32DE5 D6C2CE7A 544086DC F957A87C 2C07FF
quit
Der IOS PKI Server unterstützt die manuelle Rollover-Funktion des Zertifizierungsstellenzertifikats, d. h. ein Administrator kann die Generierung eines Rollover-Zertifizierungsstellenzertifikats im Voraus auslösen, ohne unter der PKI-Serverkonfiguration den automatischen Rollover konfigurieren zu müssen. Es wird dringend empfohlen, die automatische Rollover-Funktion zu konfigurieren, unabhängig davon, ob eine Verlängerung der Lebensdauer eines ursprünglich bereitgestellten CA-Servers geplant ist oder nicht, um die Sicherheit zu erhöhen. PKI-Clients können die CA ohne ein Rollover-CA-Zertifikat überladen. Weitere Informationen finden Sie unter Abhängigkeiten von Client-SHADOW-Operation auf PKI-Server-Rollover.
Ein manuelles Rollover kann mit dem Befehl auf Konfigurationsebene ausgelöst werden:
crypto pki server <Server-name> rollover
Außerdem kann ein Rollover-Zertifizierungsstellenzertifikat abgebrochen werden, um manuell ein neues zu generieren. Dies sollte ein Administrator jedoch in einer Produktionsumgebung nicht tun. Hierzu werden folgende Funktionen verwendet:
crypto pki server <Server-name> rollover cancel
Dadurch werden das Rollover-RSA-Schlüsselpaar und das Rollover-CA-Zertifikat gelöscht. Dies wird aus folgenden Gründen abgelehnt:
IOS auf dem PKI-Server stellt immer sicher, dass die Ablaufzeit des dem Client ausgestellten ID-Zertifikats niemals über die Ablaufzeit des Zertifizierungsstellen-Zertifikats hinausgeht.
Auf einem PKI-Client berücksichtigt IOS immer folgende Timer, bevor der Verlängerungsvorgang geplant wird:
Wenn die Ablaufzeit des Identitätszertifikats nicht mit der Ablaufzeit des Zertifizierungsstellenzertifikats übereinstimmt, führt das IOS einen einfachen Verlängerungsvorgang durch.
Wenn die Ablaufzeit des Identitätszertifikats mit der Ablaufzeit des Zertifizierungsstellenzertifikats übereinstimmt, führt das IOS einen Schattenverlängerungsvorgang durch.
Wie bereits erwähnt, führt der IOS PKI-Client einen einfachen Verlängerungsvorgang durch, wenn die Ablaufzeit des Identitätszertifikats nicht mit der Ablaufzeit des Zertifizierungsstellenzertifikats identisch ist, d. h. das Identitätszertifikat, das abläuft, bevor das Zertifikat des Emittenten eine einfache Verlängerung des Identitätszertifikats auslöst.
Sobald ein Identitätszertifikat installiert ist, berechnet IOS den RENEW-Timer für den jeweiligen Vertrauenspunkt, wie unten gezeigt:
Current-Authoritative-Time bedeutet, dass die Systemuhr eine maßgebliche Zeitquelle sein muss, wie hier beschrieben. (link to Authoritative Time Source Section) PKI-Timer werden ohne eine autoritative Zeitquelle nicht initialisiert. Folglich wird es nicht zu einer Erneuerung kommen.
Die folgenden Ereignisse finden nach Ablauf des RENEW-Timers statt:
Weitere Informationen zu dieser Paketstruktur finden Sie im SCEP-Übersichtsdokument
Hinweis: Die wichtigsten Informationen sind die RecipientInfo, die den Betreffnamen und die Seriennummer der ausstellenden CA darstellt. Der öffentliche Schlüssel dieser CA wird zur Verschlüsselung des symmetrischen Schlüssels verwendet. Der CSR im PKCS7-Umschlag wird mit diesem symmetrischen Schlüssel verschlüsselt.
Dieser verschlüsselte symmetrische Schlüssel wird von der empfangenden CA mithilfe des privaten Schlüssels entschlüsselt, und dieser symmetrische Schlüssel wird verwendet, um den PKCS7-Umschlag zu entschlüsseln, der die CSR-Nachricht preisgibt.
crypto pki trustpoint <TP>
enrollment retry count <total retry count>
enrollment retry period <first retry period in minutes>
Die PKCS7-umhüllten Daten enthalten auch einen symmetrischen Schlüssel, der mit dem öffentlichen Schlüssel des Empfängers verschlüsselt ist (für den das neue Zertifikat erteilt wurde). Der empfangende Router entschlüsselt diesen mithilfe des privaten Schlüssels. Dieser klare symmetrische Schlüssel wird dann zum Entschlüsseln der PKCS#7-umhüllten Daten verwendet, um das neue Identitätszertifikat preiszugeben.
Ein neu angemeldeter PKI-Client hätte ein Identitätszertifikat (auch Router-Zertifikat oder Endunternehmenszertifikat) und das ausstellende Zertifizierungsstellen-Zertifikat unter dem registrierten Vertrauenspunkt
PKI-Client# show crypto pki certificates
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
Time source is NTP, 14:10:38.279 CET Wed Jul 27 2016
Certificate
Status: Available
Certificate Serial Number (hex): 05
Certificate Usage: General Purpose
Issuer:
cn=RootCA
ou=TAC
o=Cisco
Subject:
Name: PKI-Client.cisco.com
Serial Number: 104
serialNumber=104+hostname=PKI-Client.cisco.com
cn=PKI-Client
ou=Root
Validity Date:
start date: 14:12:34 CET Oct 9 2015
end date: 14:12:34 CET Oct 8 2016
renew date: 14:12:18 CET Jul 27 2016
Associated Trustpoints: Root-CA
Storage: nvram:RootCA#5.cer
CA Certificate
Status: Available
Certificate Serial Number (hex): 01
Certificate Usage: Signature
Issuer:
cn=RootCA
ou=TAC
o=Cisco
Subject:
cn=RootCA
ou=TAC
o=Cisco
Validity Date:
start date: 13:14:16 CET Oct 9 2015
end date: 13:14:16 CET Oct 8 2017
Associated Trustpoints: Root-CA
Storage: nvram:RootCA#1CA.cer
Der entsprechende PKI-Timer lautet:
PKI-Client# show crypto pki timers
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
Time source is NTP, 14:29:34.054 CET Fri Oct 9 2015
PKI Timers
| 14:51.284
| 14:51.284 SESSION CLEANUP
|291d23:42:59.946 RENEW Root-CA
Die hier dargestellte Berechnung
RENEW = 0.8 ((end date: 14:12:34, Oct 8 2016) - (start date: 14:12:24, Oct 9 2015))
= 292 days from (14:12:34, Oct 9 2015)
= 291 days 23:42:59 hours from (14:29:34, Oct 9 2015)
= at 14:12:18 CET Jul 27 2016
Wenn der RENEW-Timer abläuft:
Jul 27 14:12:18.800: %PKI-6-CERTRENEWAUTO: Renewing the router certificate for trustpoint Root-CA
Jul 27 14:12:23.056: %CRYPTO-6-AUTOGEN: Generated new 2048 bit key pair
Jul 27 14:12:23.084: CRYPTO_PKI: using private key PKI-Key# for enrollment
Beachten Sie, dass der Verlängerungsantrag mit dem aktuellen aktiven ID-Zertifikat signiert wird:
Jul 27 14:12:25.117: PKI: Trustpoint Root-CA has router cert and loaded
Jul 27 14:12:25.117: PKI: Signing pkcs7 with Root-CA trustpoint router cert
Jul 27 14:12:25.117: PKI: key rollover configured and active
Wenn die erhaltene SCEP-Antwort PENDING lautet, starten wir einen POLL-Timer:
Jul 27 14:12:25.167: CRYPTO_PKI_SCEP: Client received CertRep - PENDING (F9A1FB9813EEA8AC86AE334DDC7CF488)
Jul 27 14:12:25.167: CRYPTO_PKI: status = 102: certificate request pending
PKI-Client# show crypto pki timer
PKI Timers
| 3:44.484
| 0:44.484 POLL Root-CA
Wie bereits gezeigt, folgt dieser POLL-Timer einem exponentiellen Backoff-Algorithmus, der mit 1 Minute, dann mit 2 Minuten, dann mit 4 Minuten usw. beginnt, bis die erhaltene SCEP-Antwort GRANTED ist oder das ID-Zertifikat abläuft.
Wenn der POLL-Timer abläuft und die SCEP-Antwort GRANTED lautet:
Jul 27 14:16:25.301: CRYPTO_PKI_SCEP: Client received CertRep - GRANTED (F9A1FB9813EEA8AC86AE334DDC7CF488)
Jul 27 14:16:25.301: CRYPTO_PKI: status = 100: certificate is granted
Jul 27 14:16:25.325: Newly-issued Router Cert: issuer=cn=RootCA,ou=TAC,o=Cisco serial=6
Jul 27 14:16:25.325: start date: 14:15:05 CET Jul 27 2016
Jul 27 14:16:25.325: end date: 14:15:05 CET Jul 27 2017
Jul 27 14:16:25.325: Router date: 14:16:25 CET Jul 27 2016
Jul 27 14:16:25.325: Received router cert from CA
Jul 27 14:16:25.325: CRYPTO_PKI: Setting renewal timers
Jul 27 14:16:25.325: CRYPTO_PKI: removing superceded cert serial #: 05
Jul 27 14:16:25.325: CRYPTO_PKI: Key Rollover - Switched from keypair PKI-Key# to PKI-Key
Jul 27 14:16:25.325: PKI: our cert expires before the CA cert for Root-CA
Jul 27 14:16:25.326: CRYPTO_PKI: current date: 14:16:25 CET Jul 27 2016
Jul 27 14:16:25.326: CRYPTO_PKI: seconds until reenroll: 1494854105
Jul 27 14:16:25.326: CRYPTO_PKI: cert expire date: 14:15:05 CET Jul 27 2017
Jul 27 14:16:25.326: CRYPTO_PKI: renew date: 14:15:05 CET May 15 2017
Nach der Erneuerung des Router-Zertifikats:
PKI-Client# show crypto pki certificates
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
Time source is NTP, 14:22:07.799 CET Wed Jul 27 2016
Certificate
Status: Available
Certificate Serial Number (hex): 06
Certificate Usage: General Purpose
Issuer:
cn=RootCA
ou=TAC
o=Cisco
Subject:
Name: PKI-Client.cisco.com
Serial Number: 104
serialNumber=104+hostname=PKI-Client.cisco.com
cn=PKI-Client
ou=Root
Validity Date:
start date: 14:15:05 CET Jul 27 2016
end date: 14:15:05 CET Jul 27 2017
renew date: 14:15:04 CET May 15 2017
Associated Trustpoints: Root-CA
CA Certificate
Status: Available
Certificate Serial Number (hex): 01
Certificate Usage: Signature
Issuer:
cn=RootCA
ou=TAC
o=Cisco
Subject:
cn=RootCA
ou=TAC
o=Cisco
Validity Date:
start date: 13:14:16 CET Oct 9 2015
end date: 13:14:16 CET Oct 8 2017
Associated Trustpoints: Root-CA
Storage: nvram:RootCA#1CA.cer
PKI-Client# show crypto pki timers
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
Time source is NTP, 14:22:17.231 CET Wed Jul 27 2016
PKI Timers
| 14:48.735
| 14:48.735 SESSION CLEANUP
|291d23:52:48.094 RENEW Root-CA
Der IOS-PKI-Client führt eine Schattenverlängerung durch, wenn die Ablaufzeit des Identitätszertifikats mit der Ablaufzeit des Zertifizierungsstellenzertifikats identisch ist, d. h. das Identitätszertifikat läuft gleichzeitig aus, wenn das Zertifikat des Emittenten einen Schattenverlängerungsvorgang auslöst.
Sobald ein Identitätszertifikat installiert ist, das dasselbe Enddatum wie das Zertifikat des Emittenten hat, berechnet IOS den SHADOW-Timer für den jeweiligen Vertrauenspunkt. Der Wert des SHADOW-Timers wäre also zu einem bestimmten Zeitpunkt:
Die folgenden Ereignisse finden statt, wenn der SHADOW-Timer für einen bestimmten Vertrauenspunkt abläuft:
Hinweis: Obwohl der SCEP-RFC-Entwurf angibt, dass der Antwortinhaltstyp application/x-x509-next-ca-cert sein könnte, sendet und akzeptiert die IOS-Implementierung application/x-x509-ca-cert.
Hinweis: Die Startzeit des Rollover-Zertifizierungsstellenzertifikats kann vor dem Gültigkeitsende des aktuellen aktiven Zertifizierungsstellenzertifikats liegen. Das Rollover-Zertifizierungsstellenzertifikat wird jedoch erst aktiviert, nachdem das aktuelle aktive Zertifizierungsstellenzertifikat abgelaufen ist. Cisco IOS PKI Server stellt jedoch sicher, dass ein Rollover-CA-Zertifikat mit einer Gültigkeitsbeginnzeit generiert wird, die der Gültigkeitsendzeit des aktuellen Zertifizierungsstellenzertifikats entspricht.
Weitere Informationen zu dieser Paketstruktur finden Sie im SCEP-Übersichtsdokument
Hinweis: Die wichtigsten Informationen sind hier die RecipientInfo, die die Informationen über das Rollover-CA-Zertifikat der ausstellenden Zertifizierungsstelle enthält, im Gegensatz zum derzeit aktiven Zertifikat der Zertifizierungsstelle, wie es beim Betrieb der RENEW der Fall ist.
Diesmal wird der symmetrische Schlüssel mit dem öffentlichen Schlüssel der Rollover-CA verschlüsselt. Diese Informationen werden von der Zertifizierungsstelle verwendet, um diese Anfrage mithilfe des Rollover-Zertifizierungsstellenzertifikats zu signieren.
Hinweis: IOS PKI SCEP-Debugger bezeichnen diesen Vorgang als GetNewCert, obwohl intern dieser Vorgang immer noch GetCert-Vorgang mit einer Wendung ist. Und die Wendung ist die Empfänger-Informationen, die auf das Rollover-CA-Zertifikat verweisen.
Hinweis: Die PKCS7-umhüllten Daten enthalten auch einen symmetrischen Schlüssel, der mit dem öffentlichen Schlüssel des Empfängers verschlüsselt ist [für den das Schattenzertifikat erteilt wurde]. Der empfangende Router entschlüsselt ihn mithilfe des privaten Schattenschlüssels. Dieser klare symmetrische Schlüssel wird dann zum Entschlüsseln der PKCS#7-umhüllten Daten verwendet, um das Schattenidentitätszertifikat preiszugeben.
Hinweis: Die Startdaten des erteilten Schattenzertifikats entsprechen denen des Rollover CA-Zertifikats. Dies entspricht auch den Enddaten des aktuellen aktiven Identitätszertifikats und des Zertifizierungsstellenzertifikats.
Hinweis: Die in die PKCS7-signierten Daten eingebetteten Informationen des Rollover CA-Zertifikats informieren den Client-Router darüber, dass die PKCS7-umhüllten Daten ein Schattenzertifikat enthalten.
Ab dem Beispiel PKI-Client nach der ersten Verlängerung erfolgt die zweite Verlängerung am 15. Mai.
May 15 14:15:41.264: Newly-issued Router Cert: issuer=cn=RootCA,ou=TAC,o=Cisco serial=7
May 15 14:15:41.264: start date: 14:15:10 CET May 15 2017
May 15 14:15:41.264: end date: 13:14:16 CET Oct 8 2017
May 15 14:15:41.264: Router date: 14:15:41 CET May 15 2017
May 15 14:15:41.265: PKI:Cert valid: 14:15:10 CET May 15 2017-13:14:16 CET Oct 8 2017 shadow 08:38:26 CET Sep 9 2017
Beachten Sie, dass das neue Zertifikatsablaufdatum mit dem des Zertifikats identisch ist, das das Zertifikat ausstellt. Daher startet IOS einen SHADOW-Timer, der auf 08:38:26, 9. September 2017 festgelegt wurde:
PKI-Client# show crypto pki timer
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
Time source is NTP, 14:18:32.444 CET Mon May 15 2017
PKI Timers
| 14:40.458
| 14:40.458 SESSION CLEANUP
|116d18:19:53.821 SHADOW Root-CA
Wenn der SHADOW-Timer am 9. September abläuft, wird zuerst GetNextCACert gesendet, um das Rollover-CA-Zertifikat herunterzuladen:
Sep 9 08:38:26.004: PKI: Shadow timer went off for Root-CA
Sep 9 08:38:28.019: PKI: Shadow state for Root-CA now GET_NEW_CA_CERT
Sep 9 08:38:33.027: CRYPTO_PKI_SCEP: Client sending GetNextCACert request
Sep 9 08:38:33.027: CRYPTO_PKI: Sending Next CA Certificate Request:
GET /cgi-bin/pkiclient.exe?operation=GetNextCACert&message=Root-CA HTTP/1.0
Sep 9 08:38:33.035: CRYPTO_PKI: Reply HTTP header:
HTTP/1.1 200 OK
Date: Sat, 09 Sep 2017 07:38:33 GMT
Server: cisco-IOS
Content-Type: application/x-x509-ca-cert
Sep 9 08:38:33.035: PKI: Shadow state for Root-CA now HAVE_NEW_CA_CERT
Hinweis: Ohne einen erfolgreichen GetNextCACert wird ein PKI-Client mit der Anmeldung für SHADOW nicht fortgeführt.
Wenn das Rollover-CA-Zertifikat heruntergeladen wurde, führt PKI-Client GetNextCert aus, das mit GetCert identisch ist. Das empfangene Zertifikat wird erst aktiviert, wenn das aktuelle Zertifikat abläuft:
Sep 9 08:38:33.035: PKI: Shadow state for Root-CA now GET_NEW_ROUTER_CERT
Sep 9 08:38:56.466: %CRYPTO-6-AUTOGEN: Generated new 2048 bit key pair
Sep 9 08:38:56.493: CRYPTO_PKI: using private key PKI-Key# for enrollment
Sep 9 08:38:56.493: PKI: Shadow state for Root-CA now GET_NEW_ROUTER_CERT_ACTIVE
Sep 9 08:38:56.513: PKI: Trustpoint Root-CA has router cert and loaded
Sep 9 08:38:56.513: PKI: Signing pkcs7 with Root-CA trustpoint router cert
Sep 9 08:38:56.542: CRYPTO_PKI_SCEP: Client sending GetNewCert (6C0BD832D0C3143BAB604D63D8DF1D72)
Hier gilt derselbe exponentielle Backoff-Algorithmus. Wenn eine POLL-Antwort GEWÄHRT wird:
Sep 9 08:47:56.728: CRYPTO_PKI_SCEP: Client received CertRep - GRANTED (6C0BD832D0C3143BAB604D63D8DF1D72)
Sep 9 08:47:56.728: CRYPTO_PKI: status = 100: certificate is granted
Sep 9 08:47:56.747: Newly-issued Router Cert: issuer=cn=RootCA,ou=TAC,o=Cisco serial=8
Sep 9 08:47:56.747: start date: 13:14:16 CET Oct 8 2017
Sep 9 08:47:56.747: end date: 14:15:10 CET May 15 2018
Sep 9 08:47:56.747: Router date: 08:47:56 CET Sep 9 2017
Sep 9 08:47:56.747: Shadow certificate valid
Sep 9 08:47:56.747: Received shadow router cert from CA
Sep 9 08:47:56.747: PKI: Shadow state for Root-CA now HAVE_NEW_ROUTER_CERT
Nach der Installation des Schattenzertifikats gibt der SHADOW-Timer jetzt den Zeitpunkt an, zu dem das aktuelle aktive ID-Zertifikat sowie das Zertifizierungsstellenzertifikat ablaufen. Dies ist auch ein Hinweis darauf, zu welchem Zeitpunkt das Schatten-ID-Zertifikat und das Zertifizierungsstellenzertifikat aktiviert werden:
PKI-Client#show crypto pki timers
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
Time source is NTP, 08:49:51.993 CET Sat Sep 9 2017
PKI Timers
| 14:18.013
| 14:18.013 SESSION CLEANUP
| 29d 4:24:24.754 SHADOW Root-CA
In dieser Phase sieht die Zertifikatsdatenbank wie folgt aus:
PKI-Client#show crypto pki certificates
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
Time source is NTP, 08:53:28.688 CET Sat Sep 9 2017
Router Certificate (Rollover)
Status: Available
Certificate Serial Number (hex): 08
Certificate Usage: General Purpose
Issuer:
cn=RootCA
ou=TAC
o=Cisco
Subject:
Name: PKI-Client.cisco.com
Serial Number: 104
serialNumber=104+hostname=PKI-Client.cisco.com
cn=PKI-Client
ou=Root
Validity Date:
start date: 13:14:16 CET Oct 8 2017
end date: 14:15:10 CET May 15 2018
Associated Trustpoints: Root-CA
CA Certificate (Rollover)
Status: Available
Certificate Serial Number (hex): 03
Certificate Usage: Signature
Issuer:
cn=RootCA
ou=TAC
o=Cisco
Subject:
Name: RootCA
cn=RootCA
ou=TAC
o=Cisco
Validity Date:
start date: 13:14:16 CET Oct 8 2017
end date: 13:14:16 CET Oct 8 2019
Associated Trustpoints: Root-CA
Certificate
Status: Available
Certificate Serial Number (hex): 07
Certificate Usage: General Purpose
Issuer:
cn=RootCA
ou=TAC
o=Cisco
Subject:
Name: PKI-Client.cisco.com
Serial Number: 104
serialNumber=104+hostname=PKI-Client.cisco.com
cn=PKI-Client
ou=Root
Validity Date:
start date: 14:15:10 CET May 15 2017
end date: 13:14:16 CET Oct 8 2017
Associated Trustpoints: Root-CA
Storage: nvram:RootCA#7.cer
CA Certificate
Status: Available
Certificate Serial Number (hex): 01
Certificate Usage: Signature
Issuer:
cn=RootCA
ou=TAC
o=Cisco
Subject:
cn=RootCA
ou=TAC
o=Cisco
Validity Date:
start date: 13:14:16 CET Oct 9 2015
end date: 13:14:16 CET Oct 8 2017
Associated Trustpoints: Root-CA
Storage: nvram:RootCA#1CA.cer
In dieser Phase werden die Rollover-ID und die CA-Zertifikate aktiviert, wenn die Systemuhr das Gültigkeitsstartdatum dieser Rollover-Zertifikate erreicht, das ausgelöst wird, wenn der SHADOW-Timer abläuft.
Die Einschreibung für den PKI-Client für SHADOW kann ohne ein Rollover-Zertifikat für die ausstellende CA nicht fortgesetzt werden, da das erste, das nach Ablauf des SHADOW-Timers erfolgt, eine SCEP-Anforderung mit dem GetNextCACert-Vorgang ist.
Wenn eine CA eine GetNextCACert-SCEP-Anforderung von einem Client empfängt, prüft die Zertifizierungsstelle, ob ein Zertifikat mit dem Status "Rollover CA Certificate" versehen ist, wie hier gezeigt
Wenn die CA ein Rollover-CA-Zertifikat findet, wird es im HTTP-Antworttext gesendet, wobei der HTTP-Inhaltstyp auf application/x-x509-ca-cert festgelegt ist. Obwohl der SCEP-Entwurf vorschlägt, dass der Inhaltstyp auf application/x-x509-next-ca-cert festgelegt werden soll, verwendet die IOS-Implementierung den gleichen Inhaltstyp wie bei der GetCACert-Antwort.
Wenn die CA kein Rollover-CA-Zertifikat findet, wird eine Meldung "HTTP 404 Not Found" (HTTP 404 nicht gefunden) an den Client gesendet. Der Client behandelt dies als Fehler. Tatsächlich wird jede HTTP-Antwort, die nicht die Antwort ist, für die der Inhaltstyp strikt auf "application/x-x509-ca-cert" festgelegt ist, als Fehler behandelt. Der Client versucht erneut, das Rollover-CA-Zertifikat für die nächsten 20 Tage alle 20 Sekunden zu erhalten, es sei denn, der Server antwortet mit dem Rollover-CA-Zertifikat.
Hinweis: Bei Hunderten von PKI-Clients, die mit einer CA bereitgestellt werden, die GetNextCACert unterstützt, muss der Administrator sicherstellen, dass die PKI-Clients die GetNextCACert-Anfrage ohne ein Rollover-Zertifikat starten, das auf der CA generiert wurde. Andernfalls kann es vorkommen, dass die CA nicht auf alle Anfragen einschließlich der legitimen antwortet. Ein gutes Timer-Design finden Sie in den Bereitstellungsbeispielen.
PKI-Client-Anmeldungen können fehlschlagen oder sich aufgrund von SCEP-ausstehenden Nachrichten verzögern, bei denen vom Client erwartet wird, dass er Wiederholungen durchführt.
Wenn die Kommunikation zwischen PKI-Client und PKI-Server aufgrund von TCP-Socket-Fehlern oder HTTP-Anforderungs-Timeout fehlschlägt, initialisiert PKI den CONNECT RETRY Timer auf dem Client. Bei der Initialisierung dieses Timers werden SCEP-Fehlermeldungen nicht berücksichtigt. Der CONNECT RETRY-Timer wird standardmäßig nach jedem Ausfall auf 1 Minute initialisiert, und dies wird standardmäßig 999 Mal wiederholt. Dies kann wie folgt konfiguriert werden:
crypto pki trustpoint <TP>
enrollment retry count <total retry count>
enrollment retry period <first retry period in minutes>
Dieser Timer gilt für alle Anmeldungstypen - Erstregistrierung, Verlängerung oder Schattenregistrierung.
Wenn der PKI-Client als Antwort auf seine GetCertInitial-Meldung (Anfrage zur anfänglichen Signierung des Zertifikats oder anschließendes Zertifikatsabruf) SCEP Pending (SCEP-ausstehende Nachricht vom Server) empfängt, initialisiert er den POLL-Timer. Der erste POLL-Timer wird standardmäßig auf 1 Minute initialisiert. Nachfolgende POLL-Timer folgen einem exponentiellen Backoff-Algorithmus:
Assuming that we get SCEP Pending at time "t",
and the Pending messages are sent after every GetCertInitial message -
1st POLL Timer = 1 minute [t + 1]
2nd POLL Timer = 2 minutes [t + 1 + 2 = t + 3]
3rd POLL Timer = 4 minutes [t + 7]
4th POLL Timer = 8 minutes [t + 15]
...
Hier kann das erste POLL-Timer-Intervall wie folgt konfiguriert werden:
crypto pki trustpoint <TP>
enrollment retry count <total retry count>
Der POLL-Timer wird nicht über das Gültigkeitsdatum des Zertifikats der erteilenden Zertifizierungsstelle hinaus verlängert. Hier lautet die Logik, dass das Polling für ein Zertifikat, das möglicherweise nach Ablauf des Zertifikats der ausstellenden Zertifizierungsstelle ausgestellt wurde, nicht mehr sinnvoll ist.
Wenn die PKI-Client-Anmeldung aufgrund von HTTP-Antwortanalysefehlern oder SCEP-Fehlermeldungen fehlschlägt, wird der RENEW-Timer oder der SHADOW-Timer abhängig von der automatischen Anmeldung <percentage> und der aktuellen Systemzeit neu initialisiert.
Wenn der neu berechnete Timer-Wert über die aktuelle Ablaufzeit des Identitätszertifikats hinausgeht oder das aktuelle Identitätszertifikat abläuft, werden diese Timer nicht mehr initialisiert.
Ein Administrator kann auf IOS PKI-Clients eine manuelle Zertifikatsverlängerung durchführen. Eine manuelle Erneuerung des Zertifikats folgt dieser Logik:
Hier wird davon ausgegangen, dass der betreffende Vertrauenspunkt bereits bei einer CA angemeldet ist.
Wenn die automatische Verlängerung (automatische Anmeldung <Prozentanteil> [regenerieren]) unter dem Vertrauenspunkt konfiguriert wird:
crypto pki enroll <trustpoint-name>
crypto pki enroll <trustpoint-name>
Wenn die automatische Verlängerung nicht unter dem Vertrauenspunkt konfiguriert wurde, wie hier beschrieben, wird ein SHADOW-Timer initialisiert, um GetNextCACert mit einer Lebensdauer von 90 % des Zertifizierungsstellenzertifikats auszuführen. Die manuelle Verlängerung folgt jedoch der gleichen Logik wie der Betrieb von RENEW und SHADOW auf der Grundlage der Gültigkeit des zu verlängernden Identitätszertifikats und der Gültigkeit des erteilenden Zertifizierungsstellenzertifikats.
Hinweis: Wenn ein POLL-Timer ausgeführt wird, muss der Administrator zur Durchführung einer manuellen Verlängerung die POLL-Anmeldung abbrechen, indem er den folgenden Befehl auf Konfigurationsebene ausführt: no crypto pki enroll <trustpoint>
Auf IOS-PKI-Servern kann die Erstregistrierung mithilfe der manuellen Grant-Methode gesteuert und die Verlängerungsanforderungen der Clients automatisch erteilt werden.
crypto pki server ROOTCA
database level complete
database archive pkcs12 password 7 01100F175804575D72
issuer-name CN=RootCA,OU=TAC,O=Cisco
grant auto trustpoint ROOTCA
lifetime certificate 365
lifetime ca-certificate 730
database url ftp://10.1.1.1/DB/ROOTCA/
auto-rollover 90
Beachten Sie:
crypto pki server ROOTCA grant [all | request-id-number]
Zusammenfassung aller Timer, die sorgfältig konzipiert werden müssen:
PKI-Server:
crypto pki server ROOTCA
lifetime certificate 365 -----> 2 and 3
lifetime ca-certificate 730 -----> 1
auto-rollover 90 -----> 4
PKI-Client:
crypto pki trustpoint Root-CA
auto-enroll 80 -----> 5
Ein IOS CA-Server stellt immer sicher, dass die Ablaufzeit eines Clientzertifikats der Ablaufzeit des Zertifikats des CA-Servers entspricht oder darunter liegt.
Beim Entwurf einer PKI-Bereitstellung sind folgende Aspekte von Bedeutung:
Root-CA oder untergeordnete-CA müssen ein Rollover-Zertifikat erstellen, bevor ein PKI-Client die Schattenregistrierung startet.
Ein Beispiel aus dem obigen Konfigurationsausschnitt:
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
05-Jun-2017 |
Erstveröffentlichung |