Om 'n VPN-sertifikaat te kopieer, kopieer nie die sleutel nie
'n Sertifikaat hou die publieke sleutel en ondertekende identiteit; sy private sleutel is apart. Lees die uitvoer-bondel voordat jy aanvaar dat 'n kopie kan verifieer.
Die deurloop begin by die kliënt se sertifikaatlys, waar die inskrywing 'n naam, 'n uitreiker en 'n vervaldatum wys en niks meer nie. Voer dit uit, voer dit op die tweede toestel in, en die verbinding word geweier omdat die kliënt nie kan bewys dat hy die private sleutel besit nie. Die lêer is heeltemal gekopieer; die fout is om te verwag dat 'n sertifikaat sy eie sleutel saamdra. Lees die uitvoer-dialoog voordat jy die formaat kies, en ondersoek dan die lêer wat jy werklik ontvang het.
Twee klikke, twee baie verskillende artefakte.
Lees die uitvoer-dialoog, nie die lêer-agtervoegsel nie
'n DER- of PEM-sertifikaatuitvoer bevat 'n publieke sleutel en die ondertekende identiteitsbewerings, dit is wat 'n bediener nodig het om jou te vertrou en wat 'n kliënt nodig het om 'n bediener te verifieer. 'n PKCS#12-bondel is 'n houer wat 'n sertifikaat, sy ketting en die ooreenstemmende private sleutel kan hou, beskerm deur 'n wagwoord, hoewel dit ook sonder die sleutel geskep kan word.
PEM is net 'n teks-enkodering, nie 'n belofte oor die inhoud nie. Dieselfde agtervoegsel kan 'n enkele sertifikaat of 'n lêer met verskeie gemerkte blokke beskryf, en die uitvoer-opsies besluit watter.
Die nuttige vraag is dus nooit watter uitbreiding jy gekry het nie, maar watter blokke die lêer bevat. 'n Bondel wat sonder sy sleutel uitgevoer is, is steeds 'n bondel. Kontroleer die inhoud eerder as die gewildheid van die formaat.
Ondersoek wat jy werklik gekry het
Soek die etikette voordat jy enigiets invoer, en lees dan die sertifikaatvelde om te bevestig watter identiteit jy vashou. Voer die kontroles uit op die lêer wat werklik ingevoer gaan word. Herhaal dit ná enige heruitvoer, want die opsies kan verskil.
grep -E 'BEGIN (CERTIFICATE|PRIVATE KEY|ENCRYPTED PRIVATE KEY)' bundle.pem openssl x509 -in client.crt -noout -subject -issuer -dates openssl pkey -in client.key -noout -text | head -5 openssl pkcs12 -info -in client.p12 -noout
'n Uitvoer met net 'n sertifikaatblok is 'n publieke objek en kan nie verifieer nie. 'n Sleutelblok sonder 'n sertifikaat laat jou sonder die ketting wat die bediener verwag. Die PKCS#12-inligtinguitset meld ook of 'n sleutel teenwoordig is, wat die vraag vir daardie formaat besleg. Dit noem ook die algoritme en sleutelgrootte, en dit misluk heeltemal wanneer daar geen sleutel is nie.
Plak nooit 'n lêer met 'n private sleutel in 'n ondersteuningsdraad, 'n kwessiespoorsnyer of 'n klets nie, selfs nie wanneer dit lyk soos die sertifikaat wat jy reeds gedeel het nie. Skermskote van 'n sleutelpaneel verdien dieselfde versigtigheid.
Die sleutel kan op 'n plek woon wat jy nie kan kopieer nie
Op bestuurde toestelle kan die private sleutel in die bedryfstelsel se sleutelring, 'n hardeware-token of 'n veilige omhulsel sit, met 'n beleid wat dit as nie-uitvoerbaar merk. Die sertifikaatbestuurder wys dan die publieke objek terwyl die geheim bly sit, en geen uitvoeropdrag sal 'n draagbare kopie lewer nie. Mobiele-toestelbestuur-inskrywing werk dikwels ontwerpmatig so.
Dit is 'n beheer, nie 'n hindernis om te omseil nie. Dit is onmoontlik om 'n private sleutel uit die publieke sertifikaat te rekonstrueer, en enige gereedskap wat beweer dat dit doen, doen iets anders.
Skryf 'n nuwe identiteit in eerder as om te kopieer
Die ondersteunde pad is gewoonlik om 'n afsonderlike identiteit vir die nuwe toestel in te skryf en die ou een te herroep wanneer dit aftree, sodat elke toestel onafhanklik onttrek kan word. Waar 'n uitvoer met die sleutel werklik goedgekeur is, behandel die resulterende lêer en sy wagwoord as geloofsbriewe: versleutel in rus, oorgedra oor 'n vertroude kanaal, en verwyder wanneer die inskrywing klaar is.
Verifieer deur met die ingevoerde identiteit te verifieer, nie deur te kyk of die invoer slaag nie. 'n Kliënt wat 'n publieke sertifikaat in sy stoor aanvaar, het niks oor die sleutel bewys nie.
Sluit af deur te bevestig dat die bediener die nuwe identiteit aanvaar en dat die ou een steeds optree soos die beleid bedoel. Dit voltooi die deurloop met bewyse, eerder as met 'n lêer wat korrek lyk.