Dönüştürmeden önce: SSH anahtarı ve OpenVPN sertifikası

İçe aktarma sertifika hatasıyla başarısız olur, bu yüzden bariz adım bir dönüştürme gibi görünür. Bu içgüdü insanları dosya uzantısının değiştiği ama reddin tamamen aynı kaldığı bir yola sokar. authorized_keys içindeki bir ssh-ed25519 satırı ile bir OpenVPN istemci sertifikası ayrı kimlik bilgisi nesneleridir; verenleri, kodlamaları ve iptal yolları farklıdır. Bu kontrolleri sırayla yapmak, dönüştürmenin hiç yardımcı olup olamayacağını bir dakika içinde söyler.

Elinde gerçekte hangi nesne var?

İnsanların anahtar dediği beş şey vardır ve bunlardan yalnızca biri bir TLS profilinin istediği şeydir. SSH açık anahtarı, tür öneki ve base64 yükü olan tek satırlık bir metindir. OpenSSH sertifikası, o anahtar artı bir imza, principals ve seçeneklerdir; bunları ssh-keygen kendi küçük CA'sı olarak üretir. X.509 sertifikası tamamen başka bir yapıdır: konu, geçerlilik penceresi, uzantılar ve bir sertifika yetkilisinin imzasını taşır. Özel anahtar gizli yarıdır ve verilen paket genellikle tek bir dosyada sertifika, zinciri ve özel anahtardır.

İlk test tek bir komuta mal olur. openssl'i dosyaya yönlendirin ve sertifika yapısını ayrıştırmasını isteyin:

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

Bu, yüklenemiyor veya PEM hatasıyla başarısız olursa, dosyaya ne ad verdiğinizden bağımsız olarak dosya bir X.509 sertifikası değildir. Yeniden adlandırma içindeki ASN.1'i yeniden yazmaz; açık anahtar satırını PEM başlık metnine sarmak da bunu yapmaz.

Profil en azından bir sertifika istiyor mu?

İstemci sertifikaları birkaç kimlik doğrulama yönteminden biridir ve çalışan birçok TLS profili hiçbir zaman istemci sertifikası istemez. Bir sunucu kullanıcıları bir eklenti, kullanıcı adı ve parola veya bir token arka ucu üzerinden doğrulayabilir, ama yine de istemciden sunucunun kimliğini doğrulamasını ister. Profilde istemci sertifikası yönergesi yoksa hiçbir zaman sertifika istenmez ve hiçbir dönüştürme ağ geçidini bir sertifika istemeye zorlamaz.

Daha eski statik anahtar yapılandırmaları üçüncü durumdur. TLS el sıkışmasından öncedirler ve önceden paylaşılmış gizli bir dosya beklerler; bu yüzden o alana bir açık anahtar yapıştırmak da çalışamaz. Kimlik bilgisinin yanlış olduğuna karar vermeden önce profilin gerçekte ne istediğini okuyun.

Yeniden kodlamanın yapabildikleri ve yapamadıkları

Özel anahtarların gerçekten meşru alternatif kapları vardır. Aynı RSA veya EC anahtarı geleneksel PEM, PKCS#8 veya bir PKCS#12 paketi içinde yazılabilir ve araçlar aralarında isteyerek dönüştürür. Açık anahtarların da benzer bir hikâyesi vardır: ssh-keygen bir SSH anahtarının RFC 4716 biçimini çıkarabilir ve OpenSSH kendi sertifika biçimini de anlar. Bütün bunlar temsildir ve temsil güven değildir.

Dönüştürmenin yapamadığı şey, anahtarınızı hiç görmemiş bir sertifika yetkilisinden imza oluşturmaktır. Sertifika, bir açık anahtarın belirli bir amaç için belirli bir konuya ait olduğuna dair verenin beyanıdır. Yeniden kodlama anahtarın baytlarını korur ve beyanı yok bırakır, böylece ağ geçidinin kendi güven deposuna karşı doğrulayacağı bir şey kalmaz.

Çoğu denemenin sessizce başarısız olduğu adım budur: dosya artık .crt ile bitiyor, istemci onu şikâyet etmeden okuyor ve el sıkışma yine de kesiliyor çünkü karşı taraf güvenilir bir verene kadar zincir kuramıyor.

Sertifika yetkilisi resme nerede girer

Gerçek kayıt, sizin denetlediğiniz bir anahtar çifti ve operatörün beklediği konuyu taşıyan bir sertifika imzalama isteğiyle başlar. Operatör hakkı doğrular, isteği CA anahtarıyla imzalar ve verilen sertifikayı istemcinin sunması gereken herhangi bir ara zincirle birlikte döndürür. Ardından istemcinin onu imzalayan CA sertifikasına ihtiyacı vardır, çünkü konuştuğu sunucunun aynı dağıtıma ait olduğunu doğrulamasını sağlayan odur.

O son dosyayı unutmak kolay, yerine koymak imkânsızdır. CA'nın imzalama anahtarı hiçbir zaman istemci yapılandırmasına ait değildir ve hiçbir yerel dönüştürme almanız gereken zinciri üretmez.

SSH anahtarını yeniden kullanmanın size maliyeti

Diyelim ki bir dönüştürme gerçekten kabul edilebilir bir şey üretti. Tek bir anahtar çiftini hem SSH erişimi hem de VPN kimlik doğrulaması için yeniden kullanmak yine de iki bağımsız güvenlik kararını birbirine bağlar. authorized_keys girdisini kaldırmak SSH oturum açmalarını durdurur ve aynı açık anahtar için VPN CA'sının zaten verdiği bir sertifikaya hiçbir şey yapmaz. VPN tarafı kendi mekanizmasıyla iptal edilir, yani sertifika iptal listesi veya operatörün kayıt kaydı.

Bu yüzden kontrol listesi bir numarayla değil, bir durma koşuluyla biter. openssl dosyayı sertifika olarak ayrıştırmazsa dönüştürmeyi bırakın ve neyiniz olduğunu anlatın: SSH anahtarı, SSH sertifikası, X.509 sertifikası, özel anahtar veya paket. Profil istemci sertifikası istemiyorsa durun ve sunucunun hangi kimlik doğrulama yöntemini beklediğini sorun. Ancak iki yanıt da X.509'a işaret ettiğinde kayıt sonraki adım olur ve o konuşma ilk cümlede doğru isimle çok daha hızlı ilerler.