Sertifikat wildcard yang ditandatangani sendiri

Saya menyiapkan pihole di rumah, jadi saya ingin dapat menangani permintaan untuk situs web apa pun dengan server saya sendiri, untuk menunjukkan halaman "situs ini telah diblokir".

Saya mencoba melakukan ini dengan membuat sertifikat yang ditandatangani sendiri untuk setiap url dan menginstalnya di perangkat saya. Perintah yang saya gunakan untuk menghasilkan sertifikat:

openssl genrsa 2048 > pihole.key
openssl req -new -x509 -nodes -days 36500\
    -key pihole.key \
    -subj "/C=NL/ST=Utrecht, Inc./CN=*" \
    -reqexts SAN \
    -config <(cat /etc/ssl/openssl.cnf \
        <(printf "\n[SAN]\nsubjectAltName=DNS:*,DNS:*")) \
    -out pihole.cert
openssl x509 -noout -fingerprint -text < pihole.cert > pihole.info
cat pihole.cert pihole.info > pihole.pem
service apache2 reload

Saya telah menginstal sertifikat ini di perangkat windows saya, dan windows menunjukkan bahwa itu adalah sertifikat yang valid.

Namun, chrome memberi saya NET::ERR_CERT_COMMON_NAME_INVALID, dan edge memberi saya kesalahan yang sama ( DLG_FLAGS_SEC_CERT_CN_INVALID)

Kenapa ini? Apakah CN = *tidak diizinkan? Bagaimana saya bisa mencapai apa yang saya inginkan?

Itu tidak diperbolehkan. Sebagai tambahan khusus protokol untuk validasi hostname TLS standar, semua browser web utama (klien HTTPS) pada dasarnya telah sepakat untuk membatasi sertifikat wildcard ke "eTLD + 1" - yaitu, harus ada "TLD efektif" ditambah satu lagi Komponen -wildcard.

Secara umum ini berarti membutuhkan setidaknya dua komponen ( *.example.nettidak apa-apa tapi *.nettidak, juga tidak telanjang *). Aturan "TLD efektif" memperluas ini ke sufiks multi-level sebagaimana co.ukyang digunakan orang sebagai "TLD" yang tidak dapat dibagi dalam praktiknya. (Jadi *.example.ac.ukdiizinkan tetapi *.ac.uktidak.)

Anda dapat memeriksa bagaimana daftar sufiks publik diterapkan di Chromium dan Mozilla .

Lihat diskusi terkait di Security.SE yang memiliki kutipan dari Persyaratan Dasar Forum CA-Browser Forum (yang hanya berlaku untuk CA WebPKI publik, namun tetap mencerminkan penerapan umum):

CAs AKAN mencabut sertifikat apa pun di mana karakter wildcard terjadi pada posisi label pertama tepat di sebelah kiri label "yang dikendalikan registri" atau "sufiks publik".

Untuk menghindari pembatasan ini, bangun otoritas sertifikat yang mengeluarkan sertifikat "sesuai permintaan" untuk situs web apa pun yang Anda coba kunjungi. Saya tidak tahu bagaimana itu akan diterapkan di server web biasa, tetapi ini adalah metode umum yang digunakan oleh sistem intersepsi TLS komersial; program antivirus dan malware lainnya; dan alat pengembangan seperti Burp Proxy suite.

Sebagai contoh, server web OpenResty (pada dasarnya Nginx-with-Lua) memiliki ssl_certificate_by_luaopsi untuk mengimplementasikan pembuatan sertifikat dinamis. Proksi Squid mendukung peniruan sertifikat dalam fitur ssl-bump.

Perhatikan juga bahwa SAN sepenuhnya menimpa Subjek-CN jika keduanya ada. Hal ini membuat CN sebagian besar tidak digunakan (kecuali perangkat lunak klien Anda sudah sangat kuno sehingga tidak memiliki dukungan SAN), dan untuk peramban web CA publik bahkan tidak menerimanya lagi.

Hanya ada satu wildcard dalam sertifikat (yaitu tidak *.*.example.com), hanya dapat cocok dengan satu label (yaitu hanya www, tidak www.example.com), itu hanya dapat berada di posisi paling kiri (yaitu *.www.example.comtetapi tidak www.*.example.com) dan itu tidak dapat berada di dalam akhiran publik (yaitu tidak *.com).