VPN istemci anahtarı nasıl oluşturulur ve imzalanmak üzere CSR nasıl gönderilir

Er ya da geç bir VPN kullanıcısı, yöneticinin bir sertifika oluşturabilmesi için özel anahtarı e-postayla göndermeyi teklif eder ve reddedilmesi gereken şey tam olarak bu tekliftir. İşleyen akış, anahtarı ilk komuttan itibaren istemcide tutar: istemci anahtarı üretir, bir sertifika imzalama isteği gönderir, veren onu doğrular ve yetkilendirir, imzalanan sertifika geri döner ve onu oluşturan anahtarın yanında durur. Aşağıdaki kontrol listesi her adımda kapalı biçimde başarısız olur ve asıl mesele budur, çünkü beş adımdan ikisi insanların acele ederken atladığı adımlardır.

Adım 1: anahtarı yaşayacağı yerde oluşturun

Anahtarı tutacak makinede oluşturun ve orada bırakın. Yazılım anahtarı sıkı izinleri olan bir dosyaya gider; donanım destekli veya yönetilen bir depodaki anahtar asla dosya olmaz ve kayıt yolu genellikle bir OpenSSL komutu değil ayrı bir araçtır. Ne olursa olsun, kimsenin özel yarıyı görmesine gerek yoktur.

Yazılım akışı şöyle görünür, anahtar ve istek tek oturumda oluşturulur:

umask 077
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out client.key
openssl req -new -key client.key -out client.csr -subj "/CN=alice-vpn/O=Example"

umask satırı göründüğünden daha önemlidir. O olmadan anahtar, varsayılan olarak izin veren bir sistemde herkesin okuyabileceği biçimde yazılır ve dosyayı sonradan kopyalamak bunu yayar. Mevcut bir anahtarı yeniden kullanmak, zaten korunuyorsa ve politikanıza uyuyorsa meşrudur; her cihaz için yenisini üretmek gerekçelendirmesi daha kolaydır.

Adım 2: kimliği isteğe koyun, e-postaya değil

İstek oluşturulmadan önce VPN'in gerçekte neyi doğruladığına karar verin, çünkü o yanıt CSR'nin içine aittir. OpenVPN geleneksel olarak istemci kimliğini sertifikanın ortak adına bağlar ve strongSwan gibi araçlar bir kimlik dizesini özne veya özne alternatif adıyla eşleştirir. Adımın alice olduğunu söyleyen bir e-posta kanıt değildir ve öznesi aynı şeyi söyleyen bir istek yalnızca biraz daha iyidir.

Doğrulayıcınız birini denetlediğinde özne alternatif adı ekleyin, çünkü modern eşleştirme eski CN'yi sıklıkla yok sayar:

openssl req -new -key client.key -out client.csr \
  -subj "/CN=alice-vpn/O=Example" \
  -addext "subjectAltName=DNS:alice-vpn"

CN'yi kısa, kararlı ve dizüstü modeli yerine hesaba bağlı tutun. Kullanıcının cihaz seri numarasını içeren bir ad, ilk donanım değişimini bekleyen bir destek sorunudur.

Adım 3: imzalamadan önce isteği doğrulayın

Veren iki farklı şeyi doğrular ve bunları karıştırmak klasik hatadır. Birincisi, isteğin içsel olarak tutarlı olması: imza, taşıdığı açık anahtara karşı doğrulanır. İkincisi, istekte bulunanın isteğin talep ettiği şeye hakkı olması ve buna hiçbir kriptografik denetim yanıt veremez.

Mekanik kısım tek bir komuttur ve özneyle birlikte bir doğrulama sonucu yazdırmalıdır:

openssl req -in client.csr -noout -verify -subject
openssl req -in client.csr -noout -pubkey | openssl pkey -pubin -noout -text

Bunun neyi kanıtladığına dikkat edin. Doğrulanan bir istek yalnızca gönderenin gönderim anında eşleşen özel anahtara sahip olduğunu gösterir; gönderenin öznede adı geçen kişi olduğunu kanıtlamaz ve talep edilen grup veya yol erişimini yetkilendirmez. Kayıt incelemesi ayrı bir kapıdır ve kimsenin onaylamadığı bir grup için yapılan istek sessizce düzenlenmek yerine reddedilmelidir.

Adım 4: yetkilendirin, sonra açık uzantılarla imzalayın

İmzalama, CA'nın isteği kelimesi kelimesine kabul etmek yerine politika belirlediği yerdir. Geçerlilik, anahtar kullanımı ve rol uzantısı bir uzantı dosyasına aittir, altı ay sonra hatırlamayacağınız varsayılanlara değil. VPN kimlik doğrulaması için istemci sertifikasının amaç olarak istemci kimlik doğrulamasına ihtiyacı vardır.

cat > client.ext <<'EOF'
basicConstraints = CA:FALSE
keyUsage = digitalSignature
extendedKeyUsage = clientAuth
EOF
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -days 365 -extfile client.ext -out client.crt

Zaten bir tane kullanımdaysa mevcut seri dosyasıyla -CAserial kullanın ve CA anahtarını çevrimdışı veya politikanızın adlandırdığı korumalı depoda tutun. Sertifika seri numaraları her veren için benzersiz olmalıdır; seri dosyasını sıfırdan yeniden oluşturmak, iptali belirsiz kılan çakışmaları riske atar.

Neyin verildiğini kaydedin: seri numarası, özne, talep edilen kimlik, onaylayan kişi ve bitiş. O kayıt, daha sonra bir iptal kararının dayandığı şeydir ve kayıt izi yalnızca bir posta kutusunda yaşıyorsa yalnızca sertifikadan yeniden oluşturulamaz.

Adım 5: eşleşen anahtarın yanına kurun ve çifti kanıtlayın

İstemci sertifikayı ve veren zincirini alır, asla anahtarı değil. Bağlanmadan önce, sertifikanın diskte zaten bulunan anahtarla gerçekten eşleştiğini doğrulayın, çünkü uyuşmayan bir çift çok daha sonra kafa karıştırıcı bir el sıkışma hatası üretir:

openssl x509 -in client.crt -noout -pubkey | openssl pkey -pubin -outform DER | openssl sha256
openssl pkey -in client.key -pubout -outform DER | openssl sha256

İki özet eşleşmelidir. Sonra bağlanın ve sunucunun kaydettiği kimliğin yetkilendirdiğiniz kişi olduğunu doğrulayın, yalnızca tünelin açıldığını değil. Anahtar kaybolursa veya cihaz değiştirilirse yanıt, iptal artı yeni cihazdan yeni bir istektir; yöneticiden anahtarı başka bir yerden geri göndermesini istemek orijinali kurtarmaz ve isteği güvenli kılan modeli sessizce bozar.