AWS Client VPN: sunucu sertifikası ve istemci sertifikasının rolü

Bir Client VPN uç noktası her zaman bir TLS sunucu sertifikasına ihtiyaç duyar. Bu, yönetilen uç noktanın bir istemci bağlandığında sunduğu kimliktir. Karşılıklı kimlik doğrulama kullanıldığında tek tek istemcilerin sunduğu sertifikalardan farklı bir nesnedir. Bu ikisini karıştırmak, aksi hâlde doğru olan bir ACM kurulumunun ilk bağlantıda yine de başarısız olmasının en yaygın nedenidir.

İşte konsoldan dışarıya doğru, bir bağlantının gerçekte izlediği sırayla bir yürüyüş.

İki rol, tek uç nokta

Uç nokta bir sunucu kimliğine ve isteğe bağlı olarak istemci kimliklerini doğrulama yoluna sahiptir. Bunlar ayrı ayrı yapılandırılır. Biri istemcinin hizmete güvenip güvenemeyeceğine karar verir; diğeri hizmetin istemciyi kabul edip etmeyeceğine karar verir.

Tabloyu tek bir sertifika olarak değil, üç bağımsız gereksinim olarak okuyun. Sunucu sertifikası ve özel anahtarı hizmette kalır. İstemci sertifikası ve ona karşılık gelen özel anahtar cihazda yaşar. CA malzemesi, doğrulayıcının zinciri denetlemek için kullandığı şeydir. Dizüstü bilgisayara yalnızca orta satır aittir.

ACM sunucu sertifikası ne yapar

Uç noktayı oluşturduğunuzda sunucu sertifikası, uç noktayla aynı Bölgede ACM içinde bulunmalıdır. Konsol bir ARN ister ve o ARN orada çözümlenmelidir. ACM, alan adı doğrulamasıyla sağladığınız bir sertifikayı veya anahtarı ve zinciriyle birlikte içe aktardığınızı tutabilir. İkisi de bu rolde çalışır; yenileme ve özel anahtarı kimin tuttuğu konusunda farklılaşırlar.

Sertifikayı kimin yenileyebildiğine uyan sağlama yolunu seçin, geçerli görünen bir dosya üratmış olan yolu değil.

Karşılıklı kimlik doğrulama ne ekler

Sertifika tabanlı istemci kimlik doğrulamasını seçmek ikinci bir soruyu ekler: hangi istemciler bağlanabilir. Her istemci kendi sertifikasını sunar ve karşılık gelen özel anahtara sahip olduğunu kanıtlar. Ayrı kimlikler, daha sonra seçici iptali mümkün kılan şeydir. Tek bir istemci anahtarını her cihaza kopyalamak, sunucu sertifikası kusursuz biçimde alınmış olsa bile bu özelliği sessizce çöpe atar.

Uç noktanın kimlik doğrulama yöntemi bir seçimdir, evrensel bir gereksinim değildir.

Active Directory ve federe kimlik doğrulama aynı soruyu başka araçlarla yanıtlar. Karşılıklı sertifika tarifi bu dağıtımlar için otomatik olarak oturum açma tasarımı değildir ve sunucu TLS doğrulaması, kullanıcının nasıl alındığından bağımsız olarak yürürlükte kalır.

Aynı CA ARN'si neden anahtar paylaşımı değildir

AWS, sunucu ve istemci sertifikaları aynı CA tarafından verildiğinde sunucu sertifikasının ARN'sinin istemci sertifikası seçimi için de kullanılabileceğini belgeler. O cümle, uç noktanın doğrulamada hangi zincire güvendiğiyle ilgilidir. İstemcilere sunucunun özel anahtarını kullanmalarını söylemez. Dizüstü bilgisayar yine de kendi istemci sertifikasına ve kendi karşılık gelen anahtarına ihtiyaç duyar.

İstemcinin CA'si farklı bir verici olduğunda, belgelenen yol o CA'yı ACM'ye aktarmak ve istemci rolü için seçmektir.

Hatayı bir aşamaya kadar geri izleyin

Herhangi bir şeyi değiştirmeden önce hangi aşamanın başarısız olduğunu belirleyin. İstemci uç noktayı reddediyorsa şüpheli, sunucunun ARN'si veya zinciridir. Uç nokta istemciyi reddediyorsa istemci sertifikasına, vericisine ve seçilen kimlik doğrulama yöntemine bakın. Tünel açılıyor ve trafik hâlâ başarısız oluyorsa sertifikaları çoktan geçmişsinizdir.

Nesneleri tek tek değiştirin, çünkü iki ucu birden değiştirmek başladığınız belirsizliği yeniden üretir.

Hizmetin desteklediği anahtar algoritmalarını ve belirli rol için gereken uzantıları da denetleyin. Genel bir web sitesini tatmin eden bir sertifika, tüm Client VPN kimlik gereksinimlerinin karşılandığının kanıtı değildir.

Her alanın hangi ARN'yi tuttuğunu, istemci sertifikasını hangi CA'nın verdiğini ve uç noktanın gerçekte hangi kimlik doğrulama yöntemini kullandığını yazın. Üç satır kayıt, sonraki yenilemeyi bir soruşturma yerine bir göreve dönüştürür.