Sertifikat SSTP tidak cocok: nama yang harus disajikan server Anda

SSTP klien SSTP menerima server hanya setelah validasi TLS berhasil, dan pemeriksaan itu membandingkan nama, rantai, dan tujuan. Nama berasal dari profil koneksi, bukan dari alamat yang kebetulan bisa Anda ping. Ketika salah satu dari ketiganya tidak cocok, klien melaporkan masalah sertifikat dan tidak pernah mencapai prompt masuk.

Nama profil menentukan apa yang diperiksa

SSTP menjalankan TLS di atas TCP 443, jadi klien berperilaku seperti klien TLS lainnya: ia mengambil nama host dari profil, meminta nama itu, dan membandingkan sertifikat dengannya. Jika Anda mengetik alamat IP di profil, perbandingannya menjadi perbandingan alamat IP, yang tidak dipenuhi sebagian besar sertifikat server.

Karena itu, uji di browser bisa berhasil sementara VPN gagal, sebab browser memakai nama yang berbeda dari profil. Pemisahan yang sama muncul ketika DNS split-horizon mengubah nama host VPN menjadi alamat internal sementara browser mencapai alamat publik. Selaraskan dulu profil dengan nama host yang terdokumentasi, lalu bandingkan sertifikat. Apa pun yang Anda ubah sebelum itu hanyalah dugaan.

Apa yang harus dibawa sertifikat server

Klien modern mencocokkan dengan ekstensi nama alternatif subjek, jadi nama host harus ada di sana sebagai entri DNS. Nama umum saja tidak cukup untuk tumpukan validasi saat ini, dan wildcard mencakup satu label, bukan subdomain apa pun yang Anda karang. Tiga sertifikat menggambarkan batasnya: nama yang benar dengan tujuan yang salah memvalidasi identitas lalu gagal pada pemeriksaan tujuan, nama dan tujuan yang benar dengan perantara yang hilang gagal pada rantai, dan nama yang hanya muncul di nama umum gagal sebelum salah satu dari keduanya penting.

Sertifikat juga memerlukan tujuan autentikasi server, nilai penggunaan kunci yang diperluas yang disebutkan dalam spesifikasi SSTP Microsoft, yaitu serverAuth dengan pengenal objek 1.3.6.1.5.5.7.3.1. Penggunaan kunci dan rantai yang valid melengkapi himpunan. Sertifikat yang ada di server, diterbitkan untuk nama yang benar tetapi hanya untuk autentikasi klien, tetap gagal.

Periksa rantai dan jam sebelum kredensial

Kegagalan waktu dan kepercayaan menghasilkan hasil yang terlihat sama dengan ketidakcocokan nama, dan keduanya lebih murah didiagnosis daripada masalah kata sandi. Periksa jam server dan jam klien, lalu baca rantai seperti yang dilihat klien:

# from the client, or any host that runs openssl
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -ext subjectAltName
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -verify_return_error </dev/null
# on the Windows server that holds the SSTP listener
w32tm /query /status

Perintah pertama mencetak nama, jendela validitas, dan nama alternatif yang akan dibandingkan klien. Perintah kedua melaporkan galat verifikasi dengan rantai sebagaimana disajikan, dan di situlah perantara yang hilang muncul. Di Windows, kueri layanan waktu memberi tahu apakah jam sedang dikoreksi atau hanya menyimpang.

CA internal menambahkan satu syarat lagi: klien harus memercayai CA itu. Pasang akar organisasi melalui saluran distribusi yang disetujui, bukan dari halaman yang menawarkan sertifikat pengganti, karena keputusan itu adalah seluruh model kepercayaan dalam bentuk kecil.

Validasi server dan autentikasi pengguna adalah tahapan berurutan dengan kegagalan berbeda. Galat sertifikat berarti klien tidak pernah memercayai server, sedangkan kata sandi yang ditolak berarti klien memercayai server dan kredensialnya salah. Mematikan validasi sertifikat untuk mencapai prompt kata sandi menghilangkan jaminannya alih-alih memperbaikinya. Untuk membuktikan sisa jalur bekerja, uji nama host dan port yang sama dari klien yang sudah memercayai rantai, dan biarkan profil yang diterapkan tetap apa adanya.

Perbaiki nama atau sertifikat, lalu uji ulang

Tiga kondisi menentukan perbaikannya. Jika nama profil salah, perbaiki profil atau tambahkan nama yang hilang ke sertifikat. Jika rantainya tidak lengkap, pasang perantara di server. Jika tujuannya salah, terbitkan ulang alih-alih menambal di sekitarnya.

Setelah perubahan, sambungkan kembali dengan klien yang didukung dan pastikan prompt masuk muncul, lalu terowongan naik. Catat nama host yang dipakai, penerbit, dan tanggal kedaluwarsa di tiket. Catatan itulah yang menjadikan pembaruan berikutnya tugas terjadwal alih-alih gangguan lain, dan juga menunjukkan kepada orang berikutnya kondisi mana dari ketiganya yang benar-benar rusak.