Foardat jo it omsette: SSH-kaai tsjin OpenVPN-sertifikaat

De ymport mislearret mei in sertifikaatflater, dat de foar de hân lizzende stap liket in omsetting. Dy yndruk stjoert minsken in paad del wêryn’t de triemtaheaksel feroaret en de ôfwizing krekt itselde bliuwt. In ssh-ed25519-rigel yn authorized_keys en in OpenVPN-kliïntsertifikaat binne aparte legitymaasje-objekten, mei ferskillende útjouwers, ferskillende kodearrings en ferskillende ynlûkingspaden. As jo dizze kontrôles op folchoarder trochrinne, witte jo binnen in minút oft in omsetting hielendal helpe kin.

Hokker objekt hawwe jo eins?

Der binne fiif dingen dy’t minsken in kaai neame, en mar ien dêrfan is wat in TLS-profyl wol. In iepenbiere SSH-kaai is ien rigel tekst mei in typeprefiks en in base64-lading. In OpenSSH-sertifikaat is dy kaai plus in hantekening, principals en opsjes, makke troch ssh-keygen dat as syn eigen lytse CA fungearret. In X.509-sertifikaat is in folslein oare struktuer, dy’t in subjekt, in jildichheidsfinster, útwreidings en in hantekening fan in sertifikaatautoriteit draacht. In partikuliere kaai is de geheime helte, en in útjûn pakket is meast in sertifikaat plus syn keatling plus de partikuliere kaai yn ien triem.

De earste test kostet ien opdracht. Rjochtsje openssl op de triem en freegje it de sertifikaatstruktuer te ûntlêzen:

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

As dat mislearret mei in unable-to-load- of PEM-flater, is de triem gjin X.509-sertifikaat hoe’t jo it ek neamd hawwe. In omneaming skriuwt de ASN.1 fan binnen net oer, en dat docht it ynpakken fan in iepenbiere kaairigel yn PEM-koptekst ek net.

Freget it profyl hielendal in sertifikaat?

Kliïntsertifikaten binne ien autentikaasjemetoade fan ferskate, en in soad wurkjende TLS-profylen freegje der nea ien. In server kin brûkers autentisearje fia in plugin, in brûkersnamme en wachtwurd, of in token-backend, wylst er noch altyd fan de kliïnt freget de identiteit fan de server te ferifiearjen. As it profyl gjin kliïntsertifikaat-direktive hat, sil nea in sertifikaat frege wurde, en gjin inkelde omsetting sil de gateway der ien freegje litte.

Aldere statyske-kaaikonfiguraasjes binne wer in tredde gefal. Se binne fan foar de TLS-hânskodding en ferwachtsje in triem mei in foarôf dield geheim, dat is wêrom’t it plakken fan in iepenbiere kaai yn dat fjild ek net wurkje kin. Lês wat it profyl eins freget foardat jo beslute dat it legitymaasje ferkeard is.

Wat weromkodearjen kin en net kin

Partikuliere kaaien hawwe wol legitime alternative konteners. Deselde RSA- of EC-kaai kin skreaun wurde as tradisjonele PEM, as PKCS#8, of yn in PKCS#12-pakket, en ark konvertearje der mei nocht tusken. Iepenbiere kaaien hawwe in ferlykber ferhaal: ssh-keygen kin de RFC 4716-foarm fan in SSH-kaai útjaan, en OpenSSH begrypt ek syn eigen sertifikaatformaat. Dat alles is foarstelling, en foarstelling is gjin fertrouwen.

Wat in omsetting net kin, is in hantekening meitsje fan in sertifikaatautoriteit dy’t jo kaai nea sjoen hat. In sertifikaat is in bewearing fan in útjouwer dat in beskate iepenbiere kaai by in beskate subjekt heart foar in beskaat doel. Weromkodearjen bewarret de bytes fan de kaai en lit de bewearing weilitten, dat de gateway hat neat om tsjin syn fertrouwensopslach te falidearjen.

Dit is de stap dêr’t de measte besykjen stil mislearje: de triem einiget no op .crt, de kliïnt lêst it sûnder klacht, en de hânskodding brekt dochs ôf om’t de oare partij gjin keatling nei in fertroude útjouwer bouwe kin.

Wêr’t de sertifikaatautoriteit yn byld komt

Echte ynskriuwing begjint mei in kaaipaar dat jo beheare en in sertifikaatûndertekeningsfersyk dat it subjekt draacht dat de operator ferwachtet. De operator ferifiearret it rjocht, ûndertekenet it fersyk mei de CA-kaai, en jout it útjûne sertifikaat werom tegearre mei elke tuskenlizzende keatling dy’t de kliïnt presintearje moat. Dêrnei hat de kliïnt it CA-sertifikaat nedich dat it ûndertekene hat, want dat is wat him befêstigje lit dat de server dêr’t er mei praat by deselde útrulling heart.

Dy lêste triem is maklik te ferjitten en ûnmooglik te ferfangen. De ûndertekeningskaai fan de CA sels heart nea yn de kliïntkonfiguraasje, en gjin inkelde lokale omsetting produsearret de keatling dy’t jo krije moatten hiene.

Wat it jo kostet om de SSH-kaai wer te brûken

Stel dat in omsetting dochs wat akseptabels opsmiet. It wer brûken fan ien kaaipaar foar SSH-toegong en VPN-autentikaasje keppelt noch altyd twa ûnôfhinklike feiligensbeslissingen. It fuortheljen fan in authorized_keys-yngong stopet SSH-ynloggings, en it docht neat oan in sertifikaat dat de VPN-CA al foar deselde iepenbiere kaai útjûn hat. De VPN-kant wurdt ynlutsen fia syn eigen meganisme, dat wol sizze de sertifikaatynlûkingslist of it ynskriuwingsregister fan de operator.

Dat de checklist einiget mei in stopbetingst ynstee fan in trúk. As openssl de triem net as sertifikaat ûntlêze wol, stopje dan mei omsetten en beskriuw wat jo hawwe: SSH-kaai, SSH-sertifikaat, X.509-sertifikaat, partikuliere kaai of pakket. As it profyl gjin kliïntsertifikaat freget, stopje dan en freegje hokker autentikaasjemetoade de server ferwachtet. Allinnich as beide antwurden nei X.509 wize, wurdt ynskriuwing de folgjende stap, en dat petear giet folle flugger mei it goede haadwurd yn ’e earste sin.