OpenConnect bir token için hangi PKCS#11 URI'yi ister?

Doğru anahtarı zaten taşıyan bir akıllı kart bile üzerindeki hangi nesnenin kullanılacağının söylenmesi gerekir. OpenConnect bu durumda kopyalanmış bir .key dosyası istemez; sertifikayı adlandıran bir PKCS#11 URI ister ve otomatik arama işi bitiremediğinde yanındaki özel anahtarı da ister. Can sıkıcı kısım, sözdizimsel olarak geçerli bir URI'nin hiçbir şey kanıtlamamasıdır. Kartın açmaya razı olduğu bir nesneyi değil, geçidin zaten güvendiği kaydı adlandırmalıdır.

İstemcinin dışa aktarılmış anahtar yerine istediği şey

-c seçeneği normalde bir dosya yolu alır, ancak değer PKCS#11 URI olarak ayrıştırıldığında OpenConnect onu diskteki bir dosyaya değil, tokenın içindeki bir nesneye başvuru olarak ele alır. -k seçeneği özel anahtar için aynı şekilde davranır. Hiçbir şey dışa aktarılmaz ve anahtar kartın sağladığı korumayı asla terk etmez. İstemcinin sizden ihtiyaç duyduğu şey, token modülünün, sertifika deposunun ve geçit kaydının üzerinde anlaştığı bir addır.

Çoğu denemenin tıkandığı yer bu son kısıttır. Bir URI tamamen iyi biçimlendirilmiş olabilir ve yine de geçidin reddedeceği bir sertifika seçebilir, çünkü geçerlilik ile ilgililik ayrı sorulardır. Yapmaya değer denetim, kayıt kaydıyla karşılaştırmadır; rastgele açılan ilk nesneyi aramak değildir.

İki URI, iki farklı iş

Sertifikanın URI'si hangi kimliği talep ettiğinizi yanıtlar. Genel anahtarı ve konu satırı VPN yöneticisinin verdiği hesap veya cihaz profilini eşleşen bir sertifika nesnesine işaret eder. Aynı sertifika genellikle yanında saklanan bir özel anahtar nesnesiyle birlikte gelir ve TLS el sıkışmasının gerçekte ihtiyaç duyduğu çift budur.

Anahtarın URI'si, OpenConnect bunu çıkaramadığında eşleşen özel malzemenin nerede durduğunu yanıtlar. Yalnızca -c ayarlandığında istemci sertifikanın özelliklerinden bir anahtar araması kurar; -k vermek tahmini açık bir nesne başvurusuyla değiştirir. Tokenın PIN'i üçüncü ve ilgisiz girdidir: işlem için kartın kilidini açar ve hiçbir zaman bir nesneyi tanımlamaz.

openconnect --protocol=anyconnect \
  -c 'pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=1a2b3c4d;id=%01' \
  vpn.example.net

O tırnaklı dizedeki her şey veridir. Noktalı virgüller URI özniteliklerini ayırır ve yüzde kaçışları ayrıştırmayı bozacak karakterleri kodlar, bu yüzden tüm argüman kabuktan sağlam çıkmalıdır.

Kaydınızla eşleşen URI'yi bulma

GnuTLS, p11tool aracını sunar; bu araç geçerli kullanıcının p11-kit üzerinden gerçekte neye ulaşabildiğini listeler. p11tool --list-tokens ile başlayın, ardından ilgilendiğiniz token üzerindeki sertifika nesnelerini listeleyin. Nesneler yalnızca PIN'den sonra görünüyorsa --login ekleyin ve ilk görüneni seçmek yerine konu ile vereni kayıt kaydıyla karşılaştırın.

Token hiç görünmüyorsa sorun OpenConnect'in altındadır: p11-kit o ara yazılım için kayıtlı bir modüle sahip değildir ya da modül başka bir hesap için kayıtlıdır. Sistem genelinde kayıt /etc/pkcs11/modules altında bulunur ve kullanıcı başına bir dizin sistem kopyasına dokunmadan aynı şeyi tutabilir. Modül dosyasındaki sağlayıcı yolunun, okuyucunun yazılımının gerçekten kurduğu bir kütüphaneye işaret ettiğini doğrulayın.

URI'yi listeden kopyalarken çevresindeki tırnakları koruyun. Tırnaksız noktalı virgüller argümanı ilk öznitelikte keser ve istemci sonra bulamadığı bir nesneyi bildirir.

Otomatik anahtar araması pes ettiğinde

OpenConnect sertifikanın URI'sinden bir anahtar araması türetebilir, ancak yaptığı tam eşleştirme sürüme bağlıdır ve nesne türü ile etiketin ele alınışı zaman içinde değişmiştir. URI'yi çalışana kadar kısaltma önerisi eski bir geçici çözümü anlatır, bir gerekliliği değil. Türetilen arama başarısız olursa, sertifikanın URI'sini daha belirsiz bir şeye dönüştürmek yerine anahtarı -k ile açıkça adlandırın.

İstemciyi suçlamadan önce anahtarın var olduğunu ve p11tool --list-keys ile görülebildiğini doğrulayın. Ardından nesnenin imzalama veya şifre çözme için kullanılabilir olarak işaretlendiğini denetleyin, çünkü yanlış özniteliklerle üretilen bir anahtar, URI ne kadar doğru olursa olsun el sıkışmayı tamamlayamaz. OpenVPN profilindeki serileştirilmiş pkcs11-id değerini OpenConnect seçeneğine taşımayın; iki istemci aynı kartla konuşurken bile farklı tanımlayıcı biçimleri kullanır.

URI çözülür ve PIN kabul edilir ama kimlik doğrulama yine de başarısız olursa, URI'yi ayarlamayı bırakın. Geçidin kendi hatasını okuyun, çünkü sonraki başarısızlık tokenın üstündedir.

Yalnızca URI sorunu gibi görünen başarısızlıklar

Başka bir protokol konuşan bir geçit, URI'niz doğru da olsa yanlış da olsa aynı şekilde başarısız olur. OpenConnect eski vpnc istemcisini bir nedenle değiştirdi ve kart desteği uyumsuz bir geçit protokolünü uyumlu hale getirmez. Nesne özniteliklerine bir saat daha harcamadan önce sunucunun beklenen protokolünü ve kimlik doğrulama düzenini doğrulayın.

Sunucu kimliği doğrulaması da ayrı bir katmandır. İstemci geçidin sertifikasını kendi güven deposuna karşı doğrular ve bu denetim kart kendi payını zaten yerine getirdikten sonra çalışır. Okuyucu izinleri ve durmuş bir pcscd hizmeti aynı dış belirtiyi üretir, okunamayan bir token, ama düzeltmesi çok daha basittir.

Nesneden dışarı doğru çalışın: p11tool tokenı görüyor mu, sertifikayı ve anahtarı görüyor mu, OpenConnect URI'yi kabul ediyor mu ve ancak o zaman geçit kimliği kabul ediyor mu diye sorun. Her adımın kendi hata iletisi vardır ve her biri bir sonrakinden daha ucuza test edilir.