IOS PKI-implementatiegids: certificaatvernieuwing - Overzicht en bediening

Inleiding

Dit document beschrijft gedetailleerd de certificaatoverdracht op Cisco IOS PKI-servers en -clients van Public Key Infrastructuur (PKI). 

Voorwaarden

Vereisten

Er zijn geen specifieke vereisten van toepassing op dit document.

Gebruikte componenten

De informatie in dit document is gebaseerd op deze hardware- en softwareversies:

Hardware

• ISR-G1 [8xx, 18xx, 28xx, 38xx]
• ISR-G2 [19xx, 29xx, 39xx]
• ISR-4K [43xx, 44xx]
• ASR1k
• CSR1k

in Cisco IOS®-software

• IOS
• Voor ISR-G1 - laatste 15.1(4)M*
• Voor ISR-G2 - laatste 15.4(3)M

• IOS-XE
• XE 3.15 of 15.5(2)S

Opmerking: Algemeen softwareonderhoud voor ISR-apparaten is niet langer actief, toekomstige bug-fixes of functieverbeteringen zouden een hardwareupgrade naar ISR-2 of ISR-4xxx Series routers vereisen.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u de potentiële impact van elke opdracht begrijpen.

Achtergrondinformatie

De verlenging van het certificaat, ook bekend als vernieuwingsoperatie, zorgt ervoor dat wanneer een certificaat afloopt, een nieuw certificaat klaar is om over te nemen. Vanuit het oogpunt van een PKI Server houdt deze handeling in dat het nieuwe certificaat voor het kantelen van de server ruim van tevoren wordt gegenereerd om er zeker van te zijn dat alle PKI-klanten een nieuw certificaat voor het kantelen van de client hebben ontvangen dat door het nieuwe certificaat voor het kantelen van de server is ondertekend voordat het huidige certificaat afloopt. Vanuit het oogpunt van een PKI-client, indien het client-certificaat vervalt maar het certificaat van de CA-server niet is, vraagt de klant om een nieuw certificaat en vervangt hij het oude certificaat zodra het nieuwe certificaat is ontvangen, en indien het client-certificaat vervalt op hetzelfde moment als het certificaat van de CA-server, zorgt de client ervoor dat het certificaat van de CA-server eerst wordt ontvangen en vraagt hij om een rollover-certificaat ondertekend door het nieuwe certificaat van het serveromverloopcertificaat van CA, en beide zullen worden geactiveerd wanneer de oude certificaten verlopen.

Instellen

PKI- en Eenvoudig certificeringsprotocol (SCEP) voorvereisten

Waarschuwing tijdbron

In IOS wordt de klokbron standaard als niet-gezaghebbend beschouwd, omdat de hardwarekloktijd niet de beste bron van de tijd is. Aangezien PKI tijdgevoelig is, is het belangrijk om een geldige bron van tijd te vormen met NTP. Bij een PKI-toepassing wordt aanbevolen alle clients en de server te laten synchroniseren met één NTP-server, indien nodig door meerdere NTP-servers. Meer daarover wordt in de IOS PKI-implementatiegids uitgelegd: Aanvankelijk ontwerp en implementatie

IOS formatteert de PKI-timers niet zonder een gezaghebbende klok. Hoewel NTP sterk wordt aanbevolen, kan de beheerder als tijdelijke maatregel de hardwarekloktijd als gezaghebbend aanduiden met:

Router(config)# clock calendar-valid

HTTP-communicatie

Een vereiste voor een actieve IOS PKI Server is HTTP server, die kan worden geactiveerd met deze configuratie-level opdracht:

ip http server <1024-65535>

Deze opdracht maakt HTTP-server standaard mogelijk op poort 80, die kan worden gewijzigd zoals hierboven wordt weergegeven.

PKI-clients moeten met de PKI-server via HTTP naar de geconfigureerde poort kunnen communiceren.

PKI-configuratie

Server - Rollover

De automatische kantelconfiguratie van de PKI-server ziet er zo uit:

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

De auto-omloopparameter wordt in dagen gedefinieerd. Op een meer granulair niveau ziet de opdracht er uit:

auto-rollover <days> <hours> <minutes>

Een waarde van 90 auto-omloopdatums geeft aan dat de IOS 90 dagen voor het verstrijken van het huidige servercertificaat een certificaat voor rollover-server aanmaakt en dat de geldigheid van dit nieuwe omverloopcertificaat tegelijk met de vervaltijd van het huidige actieve certificaat begint.

Auto-rollover moet zo worden geconfigureerd dat het certificaat voor kantelen CA ruim van tevoren op de PKI-server wordt gegenereerd voordat een PKI-client in het netwerk GetNextCACert-handeling uitvoert zoals wordt beschreven in het gedeelte SHADOW-overzicht hieronder.

Clientvernieuwing

De automatische configuratie van de PKI-client voor vernieuwing van het certificaat ziet er zo uit:

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 staat, de auto-inschrijving <percentage> [regenereert] opdracht dat IOS certificatievernieuwing moet uitvoeren op precies 80% van de levensduur van het huidige certificaat.

Het sleutelwoord regenereert staten dat IOS het belangrijkste-paar van RSA zou moeten regenereren dat als schaduw zeer belangrijk-paar bekend is tijdens elke certificaat vernieuwingsoperatie.

Let goed op bij het configureren van het percentage automatische inschrijving. Op elke PKI-cliënt in de installatie, indien een voorwaarde ontstaat wanneer het identiteitsbewijs op hetzelfde tijdstip als het certificaat van uitgifte van CA afloopt, moet de waarde van de auto-inschrijving altijd de [schaduw] vernieuwingsoperatie starten nadat de CA het certificaat van wederomloop heeft aangelegd. Raadpleeg het gedeelte PKI Timer-afhankelijkheden onder de voorbeelden van implementaties.

PKI-vernieuwing/Rollover-voorwaarden

In dit document worden de herhalings- en vernieuwingsoperaties van de certificaten uitvoerig behandeld en worden deze gebeurtenissen als succesvol beschouwd:

• Initialisatie van PKI-server met een geldig CA-certificaat.
• PKI-klanten zijn met succes bij de PKI-server ingeschreven. d.w.z. elke PKI-cliënt heeft het CA-certificaat en een identiteitsbewijs, ook bekend als een routercertificaat.

Het betreden van een cliënt impliceert deze gebeurtenissen. Zonder te veel in detail te gaan:

• Verificatie van schaalpunten
• inschrijving van schaalpunten

In IOS is een betrouwbaar punt een container voor certificaten. Elk betrouwbaar punt kan één actief identiteitsbewijs en/of één actief CA-certificaat bevatten. Een betrouwbaar punt wordt als echt beschouwd als het een actief CA-certificaat bevat. Het wordt als ingeschreven beschouwd als het een identiteitsbewijs bevat. Een betrouwbaar punt moet vóór een inschrijving geauthentiseerd zijn. PKI Server- en clientconfiguratie, evenals verificatie en inschrijving van vertrouwenspunten, worden in detail behandeld in IOS PKI-implementatiegids: Aanvankelijk ontwerp en implementatie

Na de CA certificatenwinning/installatie, wint de PKI client de PKI servermogelijkheden terug alvorens een inschrijving uit te voeren. CA-functies ophalen wordt in deze sectie uitgelegd.

CA-functies

In IOS, wanneer een PKI-client een CA authentiek verklaarde, met andere woorden, wanneer een beheerder een betrouwbaar punt op een IOS-router maakt en het commando crypto-encryptie uitvoert om <trustpoint-name>te authentiseren, vinden deze gebeurtenissen plaats op de router:

• IOS verstuurt een SCEP-verzoek met het type GetCACert-handeling.
• De verwachte reactie hier is een HTTP-bericht met een type toepassing/x-x509-ca-cert in geval van een CA-inzet, of toepassing/x-x509-ca-ra-cert in geval van een RA en een CA-inzet. En het HTTP lichaam bevat het CA certificaat. [en een RA-certificaat in het laatste geval].
• Na het ophalen en installeren van het CA/RA certificaat, opent de client een automatisch SCEP verzoek met GetCACaps-handeling.
• De verwachte reactie hier is een HTTP-bericht met een content-type van applicatie/x-pki-bericht, dat ook tekst/simpel kan zijn en het HTTP-orgaan bevat een reeks functies ondersteund door de CA, gescheiden door een lijnvoerteken. Een typische IOS PKI Server-respons is zoals in het onderstaande schema wordt getoond.

De reactie wordt als volgt geïnterpreteerd door de IOS PKI-client:

CA_CAP_GET_NEXT_CA_CERT
CA_CAP_RENEWAL
CA_CAP_SHA_1
CA_CAP_SHA_256

Van deze mogelijkheden richt dit document zich op deze twee.

GetNextCACert

Wanneer deze mogelijkheid door CA wordt teruggegeven, begrijpt IOS dat CA de Rollover van CA-certificaat ondersteunt. Als deze mogelijkheid wordt teruggegeven, als de opdracht automatisch registreren niet is ingesteld onder het vertrouwde punt, formatteert IOS een SHADOW-timer die is ingesteld op 90% van de geldigheid van het CA-certificaat.

Wanneer de SHADOW-timer verloopt, voert IOS GetNextCACert SCEP-handeling uit om het certificaat van Rollover CA te halen.

Opmerking: Als de opdracht automatisch registreren is geconfigureerd onder het trustpunt in combinatie met een inschrijvingsregel, wordt een RENEW-timer gestart voordat hij het vertrouwenspunt echt authentiek maakt en probeert deze constant bij de CA in te schrijven op de inschrijvingsregel, alhoewel er geen feitelijk inschrijvingsbericht [CSR] wordt verstuurd tot het vertrouwenspunt echt is.

Opmerking: GetNextCACert wordt verzonden als een mogelijkheid door de IOS PKI-server, ook al is de automatische omloopsnelheid niet ingesteld op de server

Verlengen

Met deze mogelijkheid informeert de PKI-server de PKI-client dat ze een actief ID-certificaat kan gebruiken om een certificaatondertekeningsaanvraag te ondertekenen om het bestaande certificaat te verlengen.

Meer hierover in het gedeelte Auto-Verlengen van client in PKI.

Auto-Rollover voor PKI-servers

Met de bovenstaande configuratie op de CA Server ziet u:

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

Let op:

Rollover-handeling

 Wanneer de timer voor de CS SHADOW CERT GENERATION vervalt:

• IOS genereert eerst een rollover-key-paar - het heeft momenteel dezelfde naam als het actieve key-paar met een # hash als bijlage aan deze knop toegevoegd.
  
  

  
  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
  
  

• IOS genereert vervolgens het CA-certificaat, waar de datum van de geldigheidstart dezelfde is als de datum van de geldigheideinddatum van het huidige actieve CA-certificaat.
  
  

  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

Handmatig kantelen van de PKI-server

IOS PKI Server ondersteunt het handmatig uploaden van het CA certificaat, d.w.z. dat een beheerder de generatie van een CA-certificaat vooraf kan activeren zonder dat hij de auto-omvergooi onder de PKI-serverconfiguratie hoeft te configureren. Het is sterk aanbevolen om de auto-omvergooien te configureren of niet iemand van plan is de levensduur van een aanvankelijk uitgezette CA server te verlengen om op de veiliger kant te zijn. PKI-klanten kunnen de CA overladen zonder een CA-certificaat voor het kantelen. Raadpleeg Dependency of Client SHADOW operation op PKI Server Rollover.

Er kan een handomdraai worden geactiveerd met de opdracht voor het configuratieniveau:

crypto pki server <Server-name> rollover

Bovendien kan een CA-certificaat omverwerpen om zelf een fris certificaat te genereren, maar een beheerder dient dit niet te doen in een productieomgeving, met behulp van:

crypto pki server <Server-name> rollover cancel

Hiermee worden de rollover rsa key-pair en het rollover CA-certificaat verwijderd. Dit wordt geadviseerd om:

• Zodra de CA het overloopcertificaat genereert, kunnen meerdere klanten het overloopcertificaat van CA downloaden evenals een overloopclient-certificaat dat door het overloopcertificaat van CA is ondertekend.
• In dit stadium, indien het kantelen wordt geannuleerd, moet de cliënt misschien opnieuw worden ingeschreven.

PKI-clientautomatische vernieuwing

Soorten verlenging van clientcertificaten - VERLENGEN EN SCHADUWEN

IOS op de PKI-server zorgt er altijd voor dat de vervaltijd van het aan de client afgegeven ID-certificaat nooit verder gaat dan de vervaltijd van het CA-certificaat.

Op een PKI-client houdt IOS altijd rekening met de volgende timers voordat u de hervernieuwingshandeling voorbereidt:

• Vervaltijd van de verlenging van het identiteitsbewijs
• Vervaltijd van het certificaat van de uitgevende instelling (CA)

Als de vervaltijd van het identiteitsbewijs niet de tijd van het verlooptijd van het CA certificaat is, IOS voert een eenvoudige hernieuwing uit.

Als de Vervaltijd van het Identiteitscertificaat hetzelfde is als de vervaltijd van het CA certificaat, voert IOS een schaduwvernieuwing operatie uit.

VERLENGEN - Verlenging van identiteitsbewijs van router

Zoals eerder vermeld, verricht IOS PKI-cliënt een eenvoudige hernieuwing indien de vervaltijd van het identiteitsbewijs niet dezelfde is als de vervaltijd van het CA-certificaat, d.w.z. het identiteitsbewijs dat vervalt voordat het certificaat van de uitgevende instelling een eenvoudige verlenging van het identiteitsbewijs met zich meebrengt.

Zodra een identiteitsbewijs is geïnstalleerd, berekent IOS de RENEW-timer voor het specifieke trust-punt zoals hieronder wordt weergegeven:

De huidige tijd-gezaghebbend-tijd betekent dat de systeemklok een gezaghebbende bron van tijd moet zijn zoals hier beschreven wordt. (link naar een gezaghebbende sectie van de Tijdbron) PKI-timers zullen niet worden geïnitialiseerd zonder een gezaghebbende bron van de tijd. Als gevolg daarvan zal er geen vernieuwingsoperatie plaatsvinden.

De volgende gebeurtenissen vinden plaats wanneer de RENEW-timer verstrijkt:

• IOS genereert een schaduwtoetsenbord als regenereren is ingesteld [voorbeeld: auto-inschrijving 80 regenereren]. Zonder regenereren IOS gebruikt u het momenteel actieve RSA key-paar opnieuw.
• IOS maakt een geformatteerd PKCS-10 certificaatverzoek in, dat dan in een PKCS-7 envelop wordt versleuteld. Deze enveloppe bevat ook de ontvangerInfo, die de onderwerp-naam en het serienummer van de uitgevende CA is. Deze PKCS7-enveloppe wordt op zijn beurt verpakt in een ondertekende PKCS-7-data. Tijdens de eerste inschrijving gebruikt IOS een zelfondertekend certificaat om dit bericht te ondertekenen. En tijdens de volgende inschrijvingen, d.w.z. herinschrijvingen, gebruikt IOS het actieve identiteitscertificaat om het bericht te ondertekenen. De door PKCS7 ondertekende gegevens zijn ook opgenomen in het ondertekeningscertificaat, d.w.z. het zelf ondertekende certificaat of het identiteitsbewijs.

 Raadpleeg voor meer informatie over deze pakketstructuur het SCEP - Overzicht document

Opmerking: De belangrijkste informatie hier is de Ontvangende Info die de onderwerp-naam en het serienummer van de uitgevende CA is, en de openbare sleutel van deze CA wordt gebruikt om de symmetrische sleutel te versleutelen. De CSR in de PKCS7 envelop wordt versleuteld met deze symmetrische sleutel.

Deze versleutelde symmetric-key wordt gedecrypteerd door de ontvangende CA met behulp van zijn private sleutel, en deze symmetrische toets wordt gebruikt om de PKCS7-envelop te decrypteren die de CSR onthult.

• Dit certificaatverzoek (CSR), verpakt in PKCS7-formaat, wordt vervolgens naar de CA verzonden met een SCEP-berichttype van PKCSReq en een SCEP-operatie genaamd PKIOperation.
• Als de CA het verzoek afwijst, stopt IOS de RENEW-timer. Vanaf dit punt op moet de beheerder om het identiteitsbewijs te vernieuwen een handmatige vernieuwing uitvoeren (link naar PKI client Manual-Renewal sectie)
• Als CA een status als hangend SCEP stuurt, start IOS op de PKI client een POLL-timer vanaf 60 seconden of 1 minuut. Elke keer dat een POLL-timer afloopt, stuurt IOS GetCertInitiële SCEP-bericht via een PKIO-bewerking. Als de eerste POLL-timer afloopt, als op het GetCertInitiële bericht wordt gereageerd met een SCEP-wachtstatus, wordt het eerste POLL-timer opnieuw op 1 minuut gezet, wordt de timer opnieuw op 2 minuten uitgezet, wordt de derde POLL-timer opnieuw uitgezet tot 4 minuten Dus voor de volgende 999 opnieuw per default of tot het afgeven van het CA-certificaat afloopt.
  De Polen telling en de eerste herstartperiode kunnen worden ingesteld met behulp van:

   crypto pki trustpoint <TP>
      enrollment retry count <total retry count>
      enrollment retry period <first retry period in minutes>

• Wanneer het certificaat wordt verleend op de PKI Server, wordt het volgende GetCertInitiële SCEP bericht beantwoord met een HTTP bericht van het type toepassing/x-pki-bericht en een lichaam dat een getekend PKCS#7 ondertekende gegevens bevat. Deze door PKCS7 ondertekende gegevens bevatten de SCEP status als toegekend, en ook een PKCS7-enveloppe. Deze gegevens zijn verpakt in PKCS en bevatten het afgegeven certificaat en de ontvangstinformatie, de naam en het serienummer van het zelfgetekende certificaat tijdens de eerste inschrijving en van het actieve identiteitsbewijs tijdens de herinschrijving.

De gegevens met een enveloppe van PKCS7 bevatten ook een symmetrische sleutel die versleuteld is met de openbare sleutel van de ontvanger (waarvoor het nieuwe certificaat werd toegekend). Het ontvangen van router decrypteert het met de privé sleutel. Deze duidelijke symmetrische sleutel wordt dan gebruikt om de PKCS#7 enveloped data te decrypteren, wat het nieuwe identiteitscertificaat onthult.

• In deze fase vervangt IOS het bestaande identiteitsbewijs onmiddellijk door het nieuwe certificaat. Als regenereren werd ingesteld, vervangt het schaduwpaar ook het actieve sleutelpaar.

• Ook wordt de einddatum van het nieuwe certificaat vergeleken met de einddatum van het CA-certificaat om te bepalen of de RENEW-timer moet worden geïnitialiseerd of een SHADOW-timer moet worden geïnitialiseerd zoals hier wordt uitgelegd <href Typen clientcertificaatvernieuwing - RENEW en SHADOW>

Verificatie

Een nieuw ingeschreven PKI-cliënt zou een identiteitsbewijs hebben (ook bekend als routercertificaat of eindcertificaat) en het CA-certificaat afgeven onder het ingeschreven trustpunt

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

De corresponderende PKI-timer is:

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

De berekening zoals hier getoond

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

Als de RENEW-timer verloopt:

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

Merk op dat het vernieuwingsverzoek is ondertekend met behulp van het huidige actieve ID-certificaat:

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

Als de ontvangen SCEP-reactie PENDING is, starten we een 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

Zoals eerder geïllustreerd, volgt deze POLL-timer een exponentieel backoff-algoritme, beginnend op 1 minuut, dan 2 minuten, dan 4 minuten enzovoort, totdat de ontvangen SCEP-respons wordt GRANTED of het ID-certificaat afloopt.

Wanneer de POLL-timer verloopt en de SCEP-respons wordt GEDRAGEN:

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

Na de vernieuwing van het routercertificaat:

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

SHADOW - Routeridentiteit en hernieuwing van CA-certificaten

IOS PKI-client voert een schaduwvernieuwingsoperatie uit indien de vervaltijd van het identiteitsbewijs gelijk is aan de vervaltijd van het CA-certificaat, dat wil zeggen het identiteitsbewijs dat afloopt op hetzelfde moment als het certificaat van de emittent een schaduwvernieuwingsoperatie start.

Zodra een identiteitsbewijs is geïnstalleerd, dat dezelfde einddatum heeft als het certificaat van de uitgevende instelling, berekent IOS de SHADOW-timer voor het specifieke trustpunt. Op een gegeven moment zou de waarde van de SHADOW-timer dus zijn:

De volgende gebeurtenissen vinden plaats op het moment dat de SHADOW-timer voor een bepaald betrouwbaar punt vervalt:

• IOS voert de operatie GetNextCACert SCEP uit, waarbij de verwachte reactie een HTTP-bericht is van een toepassing/x-x509-ca-cert en de instantie die PKCS7 bevat, opgemaakt Next CA-certificaat, d.w.z. het certificaat van de uitgevende instelling met de geldigheids- starttijd [of eerder] van het huidige emittentencertificaat.

Opmerking: Hoewel het ontwerp van SCEP RFC stelt dat het type reactie-inhoud toepassing/x-x509-next-ca-cert kan zijn, stuurt IOS-implementatie toepassing/x-x509-ca-cert en accepteert.

Opmerking: De begintijd van het certificaat voor het kantelen van CA kan vroeger zijn dan de eindtijd van de geldigheid van het huidige actieve certificaat van CA. Het certificaat voor het kantelen van CA wordt echter pas geactiveerd nadat het huidige actieve CA-certificaat is verlopen. Cisco IOS PKI Server zorgt er echter voor dat het certificaat van het omvergooien van CA met de tijd van de geldigheids begintijd gelijk aan de tijd van het huidige CA certificaat wordt gegenereerd.

• Als de GetNextCACert SCEP-handeling niet is geslaagd, probeert het opnieuw te starten totdat de verwachte respons is ontvangen zoals is beschreven in de laatste stap of het huidige CA (Emulation)-certificaat is verlopen.
• Als de GetNextCACert SCEP handeling slaagt, wordt het certificaat van het omvergooien CA geïnstalleerd in de database onder het punt dat als CA (Rollover) wordt vernieuwd.
• Na een succesvolle operatie GetNextCACert genereert IOS een schaduwpaar als regenereert (voorbeeld: auto-inschrijving (80 regenereren). Zonder regenereren IOS gebruikt u het momenteel actieve RSA key-paar opnieuw.
• IOS maakt een geformatteerd PKCS-10 certificaatverzoek in, dat dan in een PKCS-7 envelop wordt versleuteld. Deze enveloppe bevat ook de ontvangerInfo, die de onderwerpregel en het serienummer van het certificaat van Rollover CA van de uitgevende CA is. Deze PKCS7-enveloppe wordt op zijn beurt verpakt in een ondertekende PKCS-7-data. Dit is ondertekend met behulp van het huidige actieve identiteitsbewijs en is ook ingebed in de door PKCS7 ondertekende gegevens.

Raadpleeg voor meer informatie over deze pakketstructuur het SCEP - Overzicht document

Opmerking: De belangrijkste informatie hier is de Ontvangende Info, die de informatie bevat van het overloopcertificaat CA van de uitgevende CA, in tegenstelling tot het momenteel actieve certificaat van de CA, zoals het geval is tijdens de RENEW-operatie.

In dit geval wordt de symmetrische toets versleuteld met de openbare sleutel van het omversen van CA. En dit is de informatie die door de CA gebruikt wordt om dit verzoek te ondertekenen met het certificaat van het omvergooien CA.

Opmerking: IOS PKI SCEP debugs noemen deze handeling als GetNewCert, hoewel dit intern nog steeds GetCert-handeling is, met een twist. En de draai is de ontvanger informatie die wijst op het overloopcertificaat.

• Dit certificaatverzoek [CSR], verpakt in PKCS7-formaat, wordt vervolgens naar de CA verzonden met een SCEP-berichttype van PKCSReq en een SCEP-operatie genaamd PKIOperation.
• Vanaf hier is het proces hetzelfde als dat van de RENEW-handeling, d.w.z. POLL-timer als de SCEP-status in behandeling is en elke POLL-timer leidt tot een GetCertInitiële SCEP-bericht.
• Wanneer het certificaat wordt verleend op de PKI Server, wordt het volgende GetCertInitiële SCEP bericht beantwoord met een HTTP bericht van het type toepassing/x-pki-bericht en een lichaam dat een ondertekend PKCS7 gegevens bevat. Deze door PKCS7 ondertekende gegevens bevatten de SCEP-status zoals toegekend, ondertekend en ingesloten met de informatie van het certificaat van Rollover CA (Onderwerp-naam en serienummer) en ook gegevens met een PKCS7-enveloppe. Deze ingesloten PKCS-gegevens bevatten het toegekende schaduwcertificaat en de Opname Info, dat de onderwerpnaam en het serienummer van het huidige actieve identiteitsbewijs is.

Opmerking: De ingekapselde PKCS7-gegevens bevatten ook een symmetrische sleutel die versleuteld is met de openbare sleutel van de ontvanger [waarvoor het schaduwcertificaat werd verleend]. Het ontvangen van router decrypteert het met behulp van de schaduw privé sleutel. Deze duidelijke symmetrische sleutel wordt dan gebruikt om de PKCS#7 enveloped data te decrypteren, wat het certificaat van de schaduwidentiteit onthult.

Opmerking: De begingegevens van het toegekende schaduwcertificaat zijn dezelfde als die van het certificaat van Rollover CA. Dit is ook hetzelfde als de eindgegevens van het huidige actieve identiteitsbewijs en van het CA-certificaat.

Opmerking: De certificeringsinformatie van Rollover CA die is ingesloten met de door PKCS7 ondertekende gegevens, is een van de informatie die de clientrouter ervan in kennis stelt dat de met PKCS7 ingekapselde gegevens een schaduwcertificaat bevatten.

• Het overloopcertificaat wordt onder het trustpunt in de certificaatdatabase geïnstalleerd als een overloopcertificaat, zonder dat dit van invloed is op het huidige actieve certificaat. En als regenereren wordt ingesteld, blijft het schaduwpaar <active-keypair-naam#> behouden met zijn tijdelijke naam.
• Wanneer het huidige actieve certificaat afloopt, samen met het CA-certificaat, vervangen zowel het certificaat voor het omversen van CA en het certificaat voor het omversen van identiteit hun tegenhangers en worden het actief. Als er een schaduwsleutelpaar bestaat, vervangt het ook het oude sleutelpaar.
• Hierna wordt de einddatum van het nieuwe certificaat vergeleken met de einddatum van het CA-certificaat om te bepalen of de RENEW-timer moet worden geïnitialiseerd of een SHADOW-timer moet worden geïnitialiseerd zoals hier wordt uitgelegd <href "Typen voor verlenging van clientcertificaten - RENEW en SHADOW">

Verificatie

Uit het voorbeeld van PKI-Client hierboven, na de eerste vernieuwing, wanneer de tweede vernieuwing plaatsvindt op 15 mei.

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

Let hier op dat de nieuwe vervaldatum van het certificaat dezelfde is als die van het CA-certificaat van afgifte, dus IOS start een SHADOW-timer ingesteld op 08:38:26, 9 sep. 2017:

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

Wanneer de SHADOW-timer op 9 september verloopt, is het eerste verzonden verzoek GetNextCACert om het CA-certificaat te downloaden bij het omversen:

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

Opmerking: Zonder een succesvolle GetNextCACert kan een PKI-Client niet verder met de SHADOW-inschrijving.

Nadat het overloopcertificaat van CA is gedownload, voert PKI-Client GetNextCert uit, wat hetzelfde is als GetCert, wordt het ontvangen certificaat niet geactiveerd tot het huidige certificaat afloopt:

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 is hetzelfde exponentiële backoff-algoritme van toepassing. Wanneer een POLL-respons wordt GEGARANDEERD:

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

Zodra het schadecertificaat is geïnstalleerd, geeft de SHADOW-timer nu het tijdstip aan waarop het huidige actieve ID-certificaat en het CA-certificaat verlopen, wat ook een indicatie is van het tijdstip waarop het schaduw-ID-certificaat en het CA-certificaat worden geactiveerd:

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 deze fase ziet de certificaatdatabase er zo uit:

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 dit stadium worden de kantelings-ID en CA-certificaten geactiveerd wanneer de systeemklok de geldigheids begindatum van deze omverloopcertificaten bereikt, die wordt geactiveerd wanneer de SHADOW-timer afloopt.

Dependentie van client-SHADOW-handeling op PKI-serveromloopsnelheid

De SHADOW-inschrijving op de PKI-client kan niet doorgaan zonder een Rollover-certificaat op de uitgevende CA, omdat het eerste wat gebeurt na de vervaldatum van de SHADOW-timer een SCEP-verzoek is met de GetNextCACert-handeling.

Wanneer CA een GetNextCACert SCEP verzoek van een client ontvangt, controleert CA of het een certificaat heeft dat gemarkeerd is als Rollover CA-certificaat zoals hier wordt getoond

Als de CA een certificaat van het omversen van CA vindt, wordt het verzonden in de reactie instantie HTTP met HTTP content-type ingesteld op application/x-x509-ca-cert. Hoewel het ontwerp van het SCEP suggereert dat het type inhoud moet worden ingesteld op application/x-x509-next-ca-cert, gebruikt IOS-implementatie hetzelfde inhoudstype als het tijdens GetCACert-respons zou doen.

Als CA geen certificaat voor het omversen van CA vindt, wordt een bericht "HTTP 404 Not Found" naar de client verzonden. De cliënt beschouwt dit als een mislukking. In feite wordt elke HTTP-respons anders dan die met het content-type dat strikt is ingesteld op "application/x-x509-ca-cert" als een storing behandeld. De client probeert het CA-certificaat elke 20 seconden opnieuw te verkrijgen voor de volgende 20 dagen, tenzij de server reageert met het CA-certificaat voor kantelen.

Opmerking: met honderden PKI-klanten die zijn ingezet met een CA-ondersteuning voor GetNextCACert, moet de beheerder ervoor zorgen dat de PKI-klanten nooit het GetNextCACert-verzoek starten zonder een rollover-certificaat dat op de CA is gegenereerd. Anders kan de CA volledig nalaten om alle verzoeken, inclusief de rechtmatige, te beantwoorden. Raadpleeg de implementatievoorbeelden voor een goed timmerontwerp.

PKI-clientinschrijving - Retry-mechanismen

PKI-clientinschrijving kan mislukken of uitgesteld worden door SCEP-wachtende berichten, waarin van de client wordt verwacht dat deze opnieuw verschijnt

RETRY Timer AANSLUITEN

Wanneer de PKI-client naar PKI Server-communicatie mislukt vanwege TCP-socket fout of HTTP-aanvraag-tijdelijke oplossing, initialiseert PKI CONNECT RETRY Timer op de client. De SCEP foutmeldingen worden niet overwogen tijdens het initialiseren van deze timer. CONNECT RETRY-timer wordt standaard op 1 minuut na elke fout geïnitialiseerd, en dit wordt standaard 999 keer herhaald. Dit is compatibel met:

   crypto pki trustpoint <TP>
      enrollment retry count <total retry count>
      enrollment retry period <first retry period in minutes>

Deze timer is van toepassing op alle typen inschrijvingen - initiële, vernieuwde of schaduwinschrijving.

POLL Timer

Wanneer de PKI-client een SCEP in afwachting van het bericht van de server ontvangt als antwoord op het GetCertInitiële bericht van de client (initiële certificaataanvraag of daaropvolgende certificatenenquête), initialiseert de client POLL-timer. De eerste POLL-timer wordt standaard gestart op 1 minuut. Volgende POLL-timers volgen een exponentieel backkoff-algoritme:

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 kan het eerste POLL-timer interval worden ingesteld met behulp van:

   crypto pki trustpoint <TP>
      enrollment retry count <total retry count>

De POLL-timer wordt niet verlengd nadat het CA-certificaat is afgegeven. Hier komt de logica vandaan dat het inroepen van een certificaat dat na de vervaldatum van dat certificaat is afgegeven, niet langer nuttig is.

VERLENGEN/SHADOW-timer

Wanneer de inschrijving van de PKI-client niet verloopt vanwege een HTTP-respons bij het ontginnen van fouten of SCEP-foutmeldingen, wordt de RENEW-timer of de SHADOW-timer opnieuw geïnitialiseerd, afhankelijk van de automatische inschrijving van <percentage>en de huidige systeemtijd.

Als de herberekende waarde van de timer de huidige vervaltijd van het identiteitsbewijs overschrijdt of het huidige identiteitsbewijs vervalt, worden deze timers niet langer geformatteerd.

PKI-clientadapterverlenging

 Een beheerder kan handmatige certificaatvernieuwing op IOS PKI-clients uitvoeren. Een handmatige vernieuwing van het certificaat volgt deze logica:

In dit verband wordt ervan uitgegaan dat het betrokken trustpunt al bij een CA is ingeschreven.

Als auto-vernieuwing (automatische inschrijving <percentage> [regenereren]) is ingesteld onder het trust-punt:

• Als er een RENEW-timer wordt uitgevoerd, wat een indicatie is dat het routeridentiteitsbewijs vervalt voordat het CA-certificaat wordt afgegeven, dan voert u deze opdracht uit om een NIEUW-handeling uit te voeren zoals hier wordt beschreven <link RENEW operation Overzicht>

crypto pki enroll <trustpoint-name>

• Als er een SHADOW-timer wordt uitgevoerd, wat een indicatie is dat het certificaat van de router-identiteit tegelijkertijd met het CA-certificaat verloopt, wordt deze opdracht uitgevoerd voor een SHADOW-handeling zoals hier beschreven <link SHADOW Operations Overzicht>

crypto pki enroll <trustpoint-name>

Als de automatische vernieuwing niet is geconfigureerd onder het trustpunt, zoals hier wordt beschreven, wordt een SHADOW-timer geïnitialiseerd voor GetNextCACert tijdens een levensduur van 90% van het CA-certificaat. De handmatige vernieuwing volgt echter dezelfde logica van de RENEW- en SHADOW-operatie op basis van de geldigheid van het identiteitsbewijs dat wordt vernieuwd en de geldigheid van het certificaat van afgifte van CA.

Opmerking: Als een POLL-timer loopt, moet de beheerder om handmatige vernieuwing uit te voeren de inschrijving die POLLed wordt geannuleerd door het volgende configuratieniveau uit te voeren: geen crypto-pki-inschrijving

PKI Server - geautoriseerde automatische verlening van clientherstartaanvragen

Op IOS PKI-servers is het mogelijk om de initiële inschrijving te controleren met behulp van handmatige subsidiemethode en automatisch de aanvragen van het verlengingscertificaat van de klanten te verstrekken.

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

Let op:

• Wanneer een IOS CA/PKI Server wordt toegelaten, wordt een trustpoint automatisch gecreëerd door de zelfde naam als de PKI server, die het certificaat van de PKI Server, evenals het certificaat van de Server van het Bewerken PKI houdt.
  
  
• De opdrachtgever kent de automatische trustpoint ROOTCA als het clientcertificaat dat wordt gebruikt voor de ondertekening van het certificaat, is ondertekend/afgegeven door het PKI Server-certificaat dat is geladen in de trustpoint ROOTCA, met andere woorden als het certificaatondertekeningsverzoek een vernieuwingsverzoek is voor een certificaat dat eerder is afgegeven door de PKI-server, ROOTCA, dan wordt het verzoek automatisch ingewilligd.
  
  
• Tijdens het eerste ondertekeningsverzoek van het certificaat gebruikt een IOS PKI-client een zelfondertekend certificaat om het verzoek te ondertekenen, dat niet voldoet aan de hierboven gedefinieerde criteria voor het verlenen van auto's, en daarom worden de eerste aanvragen voor het tekenen van certificaten in de wachtrij op de PKI-server geplaatst: ROOTCA-verzoeken voor cryptoproxyserver tonen
  
  
• Deze verzoeken moeten handmatig worden ingewilligd met behulp van:

  crypto pki server ROOTCA grant [all | request-id-number]

• Deze configuratie werkt ook wanneer de PKI-server in een rollover-toestand staat, d.w.z. wanneer de PKI-server een rollover-PKI-servercertificaat heeft gegenereerd.

PKI-Timers

Een overzicht geven van alle timers die zorgvuldig ontworpen moeten worden:

• levensduur van CA-servercertificaat
  Dit is de levensduur van het CA Server-certificaat
• levensduur van clientcertificaat
  Dit is de levensduur van het certificaat dat aan een client is afgegeven door een bepaalde PKI-server
• Subordinair-CA-certificaatlevensduur
  Subordinaat-CA is een client wat de Root-CA betreft, dus de levensduur van het client-certificaat zoals gedefinieerd op de Root-CA is ook van toepassing op de subordinaat-CA
• CA-omlooptijd
  Het aantal dagen vóór de vervaltijd van het CA-certificaat.
• Verlengingstijd van client
  Dit is het percentage van de totale levensduur van het klantcertificaat.

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

Een IOS CA Server zorgt er altijd voor dat een vervaltijd van het client certificaat gelijk is aan of minder dan de vervaltijd van het CA Server certificaat.

Tijdens het ontwerpen van een PKI-plaatsing is deze timmeroverweging belangrijk:

Root-CA of Subordinaat-CA moeten een omverloopcertificaat creëren voordat een PKI-client een schaduwinschrijving start

Neem het voorbeeld uit het configuratie fragment hierboven:

• Root-CA maakt een Rollover CA-certificaat 90 dagen voor het verstrijken van de overeenkomst
• De langste geldigheidsduur van het clientcertificaat is 365 dagen.
• Als de schaduwinschrijvingsconditie optreedt, voert de klant GetNextCACert uit op 80% van 365 dagen, d.w.z. op 292e dag of 73 dagen voor de vervaltijd van het certificaat.
En omdat de CA tegen deze tijd al het overloopcertificaat heeft gegenereerd is GetNextCACert succesvol