Certificate Authority migratie

[Techno Overlord]

Ik sta op het punt om een PKI omgeving met daarin een Root CA en twee issuing CA's te migreren van Windows 2008 R2 naar Windows 2016. Er draaien geen andere server roles op de bestaande CA servers.

Mijn plan is als volgt:
- Backup maken van bestaande CA database en de configuratie beginnende bij de Root CA en daarna de twee issuing CA's
- Backup maken van bestaande CA registry settings en beginnende bij de Root CA en daarna de twee issuing CA's
- CA server role verwijderen van issuing CA1 en issuing CA2 en daarna de Root CA
- Installatie van Certificate Services op Windows 2016 server (voor het gemak heet de nieuwe eerste issuing CA CA3 en de tweede CA4)
- Installatie van Certificate Services op Windows Server 2016 voor de nieuwe Root CA
- Configureren van AD CA
- Restore Backup CA
- Restore Registry info
- Re-issue certificate templates
- Testen van de nieuwe CA's

Het gaat om wifi-telefoontoestellen die gebruik maken van de CA's en enkele printers. Op het moment dat ik de CA server roles verwijder, kunnen de wifi-telefoontoestellen niet meer authenticeren. Klopt dit? ZIjn er nog andere zaken waar ik rekening mee moet houden?

Ik heb genoeg documentatie gevonden maar ik ben even nieuwsgierig naar eventuele opmerkingen op de bekende best-practices.

[Question Mark]

Techno Overlord schreef op woensdag 30 mei 2018 @ 15:56:
Op het moment dat ik de CA server roles verwijder, kunnen de wifi-telefoontoestellen niet meer authenticeren.

Dat ligt eraan...

als een toestel net op dat moment een crl wil downloaden , lukt dat niet. Als de applicatie op die toestellen wel een geldige crl vereist, kun je inderdaad problemen krijgen.

Daarnaast ligt het nog aan de eigenschappen van het certificaat. Als de "no must staple" extensie enabled is, gaat de client (mits ondersteund) elke keer de crl controleren. Dat lukt dan ook niet.

Ik zou dan ook vooraf op een rustig moment even de ca-service disablen op je issueing CA's en de werking controleren. Dan weet je het zeker.

[Dennism]

Question Mark schreef op woensdag 30 mei 2018 @ 16:51:
[...]

Dat ligt eraan...

als een toestel net op dat moment een crl wil downloaden , lukt dat niet. Als de applicatie op die toestellen wel een geldige crl vereist, kun je inderdaad problemen krijgen.

Daarnaast ligt het nog aan de eigenschappen van het certificaat. Als de "no must staple" extensie enabled is, gaat de client (mits ondersteund) elke keer de crl controleren. Dat lukt dan ook niet.

Ik zou dan ook vooraf op een rustig moment even de ca-service disablen op je issueing CA's en de werking controleren. Dan weet je het zeker.

Je kan de CRL ook gewoon tijdelijk op een andere locatie publiceren, ik stel het altijd zo in dat de CRL van de Offline root (de naam zegt het al) sowieso niet vanaf de rootca komt. Zo kun je voor alle CRL's die je hebt een tijdelijke CRL publiceren op bijv. een machine die je speciaal voor dit doel tijdelijk installeert.

[Techno Overlord]

Volgens mij (weet dit niet zeker aangezien ik deze klus overneem van een collega die dit 7 jaar geleden heeft ingericht) staan de CRL's op webservers dus ook al haal ik die bestaande uit de lucht, dat blijft goed gaan denk ik dan. Ik lees dat jullie geen opmerkingen hebben over mijn te nemen stappen dus dat is dan weer positief.

[Question Mark]

Dennism schreef op woensdag 30 mei 2018 @ 17:37:
[...]


Je kan de CRL ook gewoon tijdelijk op een andere locatie publiceren, ik stel het altijd zo in dat de CRL van de Offline root (de naam zegt het al) sowieso niet vanaf de rootca komt.

De lokatie van een crl staat in de al uitgegeven certificaten. Je zou die lokatie kunnen veranderen, maar dan moeten alle uitgegeven certificaten vervangen worden. Even testen of dit uberhaubt een issue is, is dan wat handiger...

[Dennism]

Question Mark schreef op woensdag 30 mei 2018 @ 20:11:
[...]

De lokatie van een crl staat in de al uitgegeven certificaten. Je zou die lokatie kunnen veranderen, maar dan moeten alle uitgegeven certificaten vervangen worden. Even testen of dit uberhaubt een issue is, is dan wat handiger...

Ik bedoel eerder de locatie van "CRL.company.com" tijdelijk naar een andere (tijdelijke) webserver te verhuizen als deze nu gehost worden op (een van) de servers binnen de PKI infrastructuur en de CRL daar te parkeren terwijl je de infrastructuur migreert.

[Question Mark]

Dennism schreef op woensdag 30 mei 2018 @ 20:15:
[...]


Ik bedoel eerder de locatie van "CLR.company.com" tijdelijk naar een andere (tijdelijke) webserver te verhuizen als deze nu gehost worden op (een van) de servers binnen de PKI infrastructuur en de CLR daar te parkeren terwijl je de infrastructuur migreert.

Ah... op zo'n manier... Logisch ook...

[wagenveld]

De CRL zou niet zo'n probleem moeten zijn, wat al gezegd is. In principe heb je alleen te maken met devices die een certificaat automatisch uitgedeeld krijgen en dat even niet kunnen terwijl je aan het migreren bent.
Weet je zeker dat niet ook bijvoorbeeld alle domain members certificaten krijgen? Zorg voor een goede inventaris van gebruikte certificaten.

En kijk even of je een cleanup nodig hebt, kan nogal wat schelen in database grootte en ruimt lekker op: https://blogs.technet.mic...tes-from-the-ca-database/

[Techno Overlord]

Het gaat met name om wifi telefoontoestellen en een paar CoW's. Dat zijn Computers-on-Wheels. Die roamen door het gebouw over verschillende SSID's.

Het innemen van deze apparaten om te voorzien van nieuwe certificaten willen we voorkomen aangezien het er heel veel zijn (2000+) en ze niet over-the-air voorzien kunnen worden van nieuwe certs maar daarvoor in een cradle geplaatst moeten worden.

Kick

[Techno Overlord]

Even een update.

Het blijkt dat CDP en AIA locaties van de twee issuing CA's draaien op elkaar. De CDP en AIA locaties van CA1 draait op CA2 en vice versa. De locaties staan er hardcoded in met de hostnames.

We willen dus voorkomen dat we alle devices moeten innemen voor het voorzien van nieuwe certificaten. Ik heb daarom ervoor gekozen om de Windows 2016 Servers dezelfde hostnames en IP-adressen te gaan geven als de oude Root en Issuing CA servers.

Ik moet dan goed opletten en ervoor zorgen dat de CDP, AIA, LDAP en HTTP locaties hetzelfde blijven, anders valt de hele boel om.

Is dit een werkbaar scenario en heeft dit kans van slagen?

[ Voor 4% gewijzigd door Techno Overlord op 20-06-2018 10:53 ]

[ElCondor]

Volgens mij is het zelfs verplicht om bij het migreren van een bestaande CA de hostnames hetzelfde te houden. Dus ja, dit zou een werkbare situatie moeten zijn

[Techno Overlord]

ElCondor schreef op dinsdag 26 juni 2018 @ 09:11:
Volgens mij is het zelfs verplicht om bij het migreren van een bestaande CA de hostnames hetzelfde te houden. Dus ja, dit zou een werkbare situatie moeten zijn

Nu ik een stuk dieper in de materie zit, zie ik ook dat het gebruiken van dezelfde hostnames vaak voorkomt maar het migreren naar servers met een andere hostname komt ook vaak voor. Nadeel is dan dus dat alle devices opnieuw moeten worden voorzien van nieuwe certificaten. Laat dat nou nét zijn wat ik wil voorkomen.

Waar ik nog mee zitt is met de instellingen van IIS. Deze IIS instellingen gaan volgens een export van de huidige configuratie en een import hiervan op de nieuwe servers niet mee over. Dit moet apart geconfigureerd worden. Ik weet niet zeker of hiervan ook de configuratie kan worden geëxporteerd en weer worden kan worden geïmporteerd in de nieuwe IIS op de nieuwe servers. Hiervan lees ik niets in de documentatie over PKI migratie.

Iemand toevallig best practice wat dit betreft?

[ElCondor]

Het hele proces van het backuppen en restoren van de CA instellingen is juist bedoeld om de hele Certificate chain te behouden in de nieuwe situatie. Het feit dat je de machines dan ook dezelfde naam moet geven als de oude is een onderdeel van de voorwaarde om de CA chain geldig te houden. Dit is dus precies wat je zoekt, volgens mij.

Ik heb het twee keer gedaan, van 2003 naar 2008R2 en van 2008R2 naar 2012.
Onlangs heb ik, bij overstap naar 2016 ervoor gekozen om een hele nieuwe CA in te richten, omdat ik maar 8 machines had die certificaten gingen betrekken en geen Exchange meer. Dus dat scheelt een hoop.