Abans de convertir-lo: clau SSH o certificat OpenVPN

La importació falla amb un error de certificat, així que el moviment obvi sembla una conversió. Aquest instint porta la gent per un camí on l’extensió del fitxer canvia i el rebuig continua exactament igual. Una línia ssh-ed25519 a authorized_keys i un certificat de client OpenVPN són objectes de credencials separats, amb emissors diferents, codificacions diferents i camins de revocació diferents. Recórrer aquestes comprovacions en ordre us diu en un minut si la conversió pot ajudar de bon principi.

Quin objecte teniu en realitat?

Hi ha cinc coses que la gent anomena clau, i només una és el que vol un perfil TLS. Una clau pública SSH és una sola línia de text amb un prefix de tipus i una càrrega base64. Un certificat OpenSSH és aquesta clau més una signatura, principals i opcions, produïts per ssh-keygen fent de la seva pròpia CA petita. Un certificat X.509 és una estructura completament diferent, que porta un subjecte, una finestra de validesa, extensions i una signatura d’una autoritat de certificació. Una clau privada és la meitat secreta, i un paquet emès sol ser un certificat més la seva cadena més la clau privada en un sol fitxer.

La primera prova costa una ordre. Apunteu openssl al fitxer i demaneu-li que analitzi l’estructura del certificat:

openssl x509 -in client.crt -noout -subject -issuer

Si això falla amb un error de no es pot carregar o PEM, el fitxer no és un certificat X.509 sigui quin sigui el nom que li hàgiu posat. Canviar el nom no reescriu l’ASN.1 de dins, i embolcallar una línia de clau pública en text de capçalera PEM tampoc no ho fa.

El perfil demana cap certificat?

Els certificats de client són un mètode d’autenticació entre diversos, i molts perfils TLS que funcionen no en demanen mai cap. Un servidor pot autenticar usuaris amb un connector, un nom d’usuari i contrasenya, o un backend de testimonis, mentre continua exigint al client que verifiqui la identitat del servidor. Si el perfil no porta cap directiva de certificat de client, no es demanarà mai cap certificat, i cap conversió farà que la passarel·la en demani un.

Les configuracions antigues de clau estàtica són un tercer cas. Són anteriors a l’apretada de mans TLS i esperen un fitxer de secret compartit prèviament, i per això enganxar una clau pública en aquell camp tampoc no pot funcionar. Llegiu què demana realment el perfil abans de decidir que la credencial és incorrecta.

Què pot i què no pot fer la recodificació

Les claus privades sí que tenen contenidors alternatius legítims. La mateixa clau RSA o EC es pot escriure com a PEM tradicional, com a PKCS#8 o dins d’un paquet PKCS#12, i les eines convertiran entre ells amb molt de gust. Les claus públiques tenen una història semblant: ssh-keygen pot emetre la forma RFC 4716 d’una clau SSH, i OpenSSH també entén el seu propi format de certificat. Tot això és representació, i la representació no és confiança.

El que la conversió no pot fer és crear una signatura d’una autoritat de certificació que mai no ha vist la vostra clau. Un certificat és una afirmació d’un emissor que una clau pública determinada pertany a un subjecte determinat per a una finalitat determinada. La recodificació conserva els bytes de la clau i deixa l’afirmació absent, així que la passarel·la no té res per validar contra el seu magatzem de confiança.

Aquest és el pas on la majoria d’intents fallen en silenci: el fitxer ara acaba en .crt, el client el llegeix sense queixar-se, i l’apretada de mans encara s’avorta perquè l’altra part no pot construir una cadena fins a un emissor de confiança.

On entra en joc l’autoritat de certificació

L’enregistrament real comença amb un parell de claus que controleu i una sol·licitud de signatura de certificat que porta el subjecte que l’operador espera. L’operador verifica el dret, signa la sol·licitud amb la clau de la CA i retorna el certificat emès juntament amb qualsevol cadena intermèdia que el client hagi de presentar. Aleshores el client necessita el certificat de la CA que el va signar, perquè és el que li permet confirmar que el servidor amb qui parla pertany al mateix desplegament.

Aquest darrer fitxer és fàcil d’oblidar i impossible de substituir. La clau de signatura de la CA mateixa no pertany mai a la configuració del client, i cap quantitat de conversió local produeix la cadena que havíeu de rebre.

Què us costa reutilitzar la clau SSH

Suposeu que una conversió sí que va produir alguna cosa acceptable. Reutilitzar un parell de claus per a l’accés SSH i l’autenticació VPN encara acobla dues decisions de seguretat independents. Treure una entrada d’authorized_keys atura els inicis de sessió SSH i no fa res a un certificat que la CA de la VPN ja ha emès per a la mateixa clau pública. El costat VPN es revoca pel seu propi mecanisme, és a dir, la llista de revocació de certificats o el registre d’enregistrament de l’operador.

Per tant, la llista de comprovació acaba amb una condició d’aturada en lloc d’un truc. Si openssl no analitza el fitxer com a certificat, atureu la conversió i descriviu què teniu: clau SSH, certificat SSH, certificat X.509, clau privada o paquet. Si el perfil no demana cap certificat de client, atureu-vos i pregunteu quin mètode d’autenticació espera el servidor. Només quan les dues respostes apunten a X.509 l’enregistrament esdevé el pas següent, i aquesta conversa va molt més de pressa amb el nom correcte a la primera frase.