Decoder CSR

Apa yang ada di dalam CSR, dan apa yang tidak

Certificate signing request (CSR) berisi tiga hal: subject yang ingin dicantumkan, bagian publik dari pasangan kunci Anda, dan ekstensi yang diminta - terutama subject alternative name (SAN). CSR ditandatangani dengan kunci privat Anda, yang membuktikan kepada certificate authority (CA) bahwa Anda benar-benar memegang kunci yang dimintakan sertifikatnya.

CSR tidak berisi kunci privat, dan tidak ada isinya yang bisa dipakai untuk menurunkannya. Karena itulah CSR bukan rahasia seperti kunci, dan wajar saja menempelkannya ke sebuah alat. Tetapi CSR juga bukan tanpa informasi: di dalamnya ada nama host, organisasi, dan kadang konvensi penamaan internal, jadi ada baiknya mengetahui apakah decoder yang Anda pakai mengirimkannya ke suatu tempat. Banyak yang melakukannya, karena sebagian besar dijalankan oleh perusahaan penjual sertifikat.

Perlu juga diketahui betapa sedikit isi CSR yang tersisa. CA memvalidasi nama-nama, lalu menerbitkan sertifikat dengan nomor seri, masa berlaku, penerbit, dan pertimbangannya sendiri tentang ekstensi apa yang perlu ada. Kolom organisasi dan lokasi diambil dari catatan yang sudah divalidasi CA, bukan dari yang Anda ketik. Dalam praktiknya, yang terbawa hanyalah kunci publik dan nama-nama.

Common Name sudah usang; yang penting adalah SAN

Karena alasan historis, common name (CN) pada subject terlihat seperti kolom yang menamai situs, padahal sudah bertahun-tahun tidak berfungsi demikian. Chrome berhenti memakainya pada 2017, browser lain menyusul, dan CA/Browser Forum mewajibkan setiap nama yang dicakup sertifikat tercantum di ekstensi subject alternative name. Sertifikat yang punya CN tetapi tanpa SAN ditolak oleh semua klien saat ini, apa pun isi CN-nya.

Jadi daftar SAN adalah kolom pertama yang harus dibaca, dan harus berisi setiap nama host yang dilayani sertifikat - termasuk domain tanpa www jika domain itu juga dilayani. Wildcard hanya mencakup tepat satu label, sehingga *.example.com cocok dengan www.example.com tetapi tidak dengan example.com maupun a.b.example.com.

Di dalam CSR, SAN mudah terlewat, dan banyak decoder memang melewatkannya. Pada sertifikat yang sudah terbit, SAN adalah ekstensi tingkat atas; pada request, SAN bersarang di dalam atribut extensionRequest, dua tingkat lebih dalam. Alat ini mencarinya di tempat yang benar, jadi jika daftarnya kosong di sini, CSR tersebut memang tidak memiliki SAN - dan sebaiknya diperbaiki sebelum dikirim.

Membaca sertifikat

Selain subject dan masa berlaku, beberapa ekstensi menentukan apa yang boleh dilakukan sebuah sertifikat, dan di situlah jawaban yang menarik biasanya berada.

Basic constraints menyatakan apakah ini sertifikat CA. CA:TRUE pada sertifikat leaf adalah kesalahan penerbitan yang serius; sertifikat server seharusnya menunjukkan CA:FALSE. Key usage dan extended key usage mempersempit penggunaan kunci - serverAuth untuk server TLS, clientAuth untuk mutual TLS - dan sertifikat yang tidak memiliki penggunaan yang diharapkan klien akan ditolak meskipun semua hal lain benar.

Authority information access berisi URL sertifikat penerbit, yang dipakai sebagian klien untuk melengkapi rantai yang tidak lengkap, serta URL responder OCSP. Timestamp certificate transparency menunjukkan bahwa sertifikat telah dicatat secara publik, yang kini diwajibkan browser. Authority key identifier dan subject key identifier adalah nilai yang benar-benar dicocokkan saat membangun rantai, dan lebih andal daripada membandingkan teks issuer dan subject dengan mata.

Untuk fingerprint, utamakan SHA-256; SHA-1 hanya ditampilkan karena banyak konsol dan konfigurasi pinning masih mencantumkannya. Keduanya dihitung dari encoding DER dan sama dengan hasil openssl.

Masalah rantai sertifikat

Kegagalan sertifikat yang paling umum sebenarnya bukan pada sertifikatnya, melainkan pada rantainya: server yang berjalan di browser desktop tetapi gagal di curl, aplikasi mobile, atau klien JVM.

Server harus menyajikan sertifikatnya sendiri beserta semua sertifikat intermediate hingga sebelum root. Browser sering menutupi intermediate yang hilang dengan mengambilnya dari URL authority information access atau memakai salinan yang tersimpan di cache dari situs lain, sehingga masalahnya tidak terlihat oleh orang yang menguji di Chrome tetapi langsung muncul di semua klien lain. Mengirim root juga tidak berbahaya, tetapi tidak ada gunanya - klien sudah memilikinya atau memang tidak memercayainya.

Urutan penting dalam rantai TLS klasik: leaf lebih dulu, lalu setiap penerbit secara berurutan. Menempelkan rantai lengkap di sini akan mendekode setiap blok secara terpisah sesuai urutan yang diberikan, sehingga intermediate yang hilang atau salah posisi langsung terlihat. Cocokkan issuer setiap sertifikat dengan subject sertifikat berikutnya, dan periksa juga tanggal kedaluwarsa intermediate - intermediate juga bisa kedaluwarsa, dan intermediate yang kedaluwarsa merusak sertifikat leaf yang sebenarnya valid.

Membuat permintaan, dan kunci di baliknya

CSR selalu dibuat bersamaan dengan pasangan kunci, dan kuncinyalah yang benar-benar penting. Perintah yang lazim dipakai menghasilkan keduanya sekaligus: openssl req -new -newkey rsa:2048 -nodes -keyout example.key -out example.csr. Flag -nodes membiarkan kunci tidak terenkripsi, yang memang dibutuhkan server web agar bisa menyala tanpa diminta frasa sandi, dan itu pula sebabnya berkas tersebut hanya boleh terbaca oleh akun layanan.

Dari sisi kompatibilitas, RSA 2048 bit masih menjadi pilihan bawaan yang aman. ECDSA pada kurva P-256 memberi tingkat keamanan setara dengan kunci yang jauh lebih kecil dan handshake yang lebih cepat, dibuat dengan openssl ecparam -genkey -name prime256v1, dan semua peramban masa kini menerimanya. Sebagian middlebox lawas dan klien Java warisan tidak menerimanya, dan hanya itulah alasan nyata yang tersisa untuk tetap memakai RSA.

Subject alternative name adalah kolom yang paling sering terlupakan, karena prompt interaktifnya memang tidak menanyakannya. Kolom ini harus diisi lewat berkas konfigurasi atau flag -addext, misalnya -addext "subjectAltName=DNS:example.com,DNS:www.example.com". Permintaan tanpa kolom itu akan ditolak atau, lebih buruk lagi, tetap diterbitkan sebagai sertifikat yang tidak akan diterima peramban mana pun.

Penerbitan otomatis mengubah alur kerjanya

Siklus manual - membuat CSR, menempelkannya ke portal vendor, menunggu, mengunduh sertifikat, memasangnya, lalu mengulanginya tahun depan - kini justru menjadi pengecualian. Protokol ACME, yang diperkenalkan Let's Encrypt pada 2016, mengotomatiskan seluruh pertukaran itu: klien membuktikan kendali atas domain, mengirimkan CSR, dan menerima sertifikat, biasanya dalam hitungan detik dan tanpa campur tangan manusia.

Kendali atas domain dibuktikan dengan salah satu dari tiga cara. HTTP-01 menyajikan sebuah token di jalur well-known, sehingga port 80 harus bisa dijangkau. DNS-01 menerbitkan record TXT, dan ini satu-satunya metode yang bisa menerbitkan sertifikat wildcard sekaligus satu-satunya yang berjalan pada host tanpa server web publik. TLS-ALPN-01 menjawab handshake khusus di port 443, berguna ketika hanya port itu yang terbuka.

Sertifikat yang diterbitkan dengan cara ini sengaja dirancang berlaku 90 hari, dengan alasan bahwa masa hidup yang pendek membatasi kerugian akibat kunci yang bocor dan memaksa jalur perpanjangan menjadi otomatis, bukan sesuatu yang harus diingat. Klien memperbarui sertifikat sekitar dua pertiga masa berlakunya, sehingga kegagalan masih sempat diketahui sebelum ada yang kedaluwarsa.

Tingkat validasi, wildcard, dan apa yang sebenarnya dibuktikan sertifikat

Validasi domain hanya membuktikan bahwa siapa pun yang meminta sertifikat itu memegang kendali atas domain tersebut pada saat itu. Validasi organisasi dan extended validation menambahkan pemeriksaan terhadap badan hukum di baliknya, yang lalu muncul pada kolom subject sertifikat yang diterbitkan. Peramban sudah bertahun-tahun tidak lagi memberi perlakuan antarmuka khusus untuk EV, sehingga perbedaan praktisnya hari ini lebih bersifat kontraktual dan prosedural ketimbang sesuatu yang bisa dilihat pengunjung.

Wildcard mencakup tepat satu label: *.example.com cocok dengan www dan api, tetapi tidak dengan example.com itu sendiri dan tidak pula dengan a.b.example.com. Itulah sebabnya sebagian besar sertifikat wildcard mencantumkan domain telanjangnya sebagai SAN tambahan. Wildcard juga memusatkan risiko, karena satu kunci yang bocor memengaruhi setiap host di bawah nama tersebut, dan ia tidak bisa diterbitkan tanpa kendali atas DNS.

Tak satu pun dari semua itu mengatakan apa pun tentang layak tidaknya situs itu dipercaya. Sertifikat berarti koneksinya terenkripsi dan namanya cocok; ia tidak pernah berarti bahwa pengelolanya jujur. Situs phishing lazim memiliki sertifikat yang sah, dan karena itulah antarmuka peramban berhenti memberi kesan sebaliknya.

Kedaluwarsa adalah masalah operasional, bukan masalah sertifikat

Gangguan layanan akibat sertifikat kedaluwarsa cukup sering terjadi sampai bisa disebut satu genre tersendiri: ia pernah melumpuhkan jaringan pembayaran, operator seluler, dan konsol cloud. Sertifikatnya melakukan persis apa yang memang dirancang untuk dilakukannya; yang gagal adalah proses di sekelilingnya.

Pemantauan sebaiknya memberi peringatan berdasarkan sisa hari, bukan menunggu kegagalan, dengan ambang yang cukup jauh agar masih ada waktu bertindak - dua minggu untuk sertifikat 90 hari, sebulan untuk sertifikat setahun. Pantau endpoint-nya, bukan berkasnya, karena sertifikat yang menentukan adalah yang benar-benar disajikan server, dan periksa juga sertifikat perantaranya: sertifikat perantara juga kedaluwarsa, dan perantara yang kedaluwarsa akan merusak sertifikat leaf yang sebenarnya masih sah.

Log certificate transparency memberi Anda inventaris gratis. Setiap sertifikat yang dipercaya secara publik tercatat di sana, jadi pencarian atas domain Anda akan menampilkan apa saja yang ada, termasuk sertifikat yang diterbitkan orang lain di organisasi Anda dan lupa dikabarkan.

Membaca rantai sertifikat saat ada yang tidak beres

Satu perintah yang paling berguna adalah openssl s_client -connect host:443 -servername host, yang menunjukkan apa yang benar-benar disajikan server, bukan apa yang tertulis di berkas konfigurasi Anda. Rantai yang dicetaknya harus dimulai dari sertifikat leaf lalu berlanjut ke setiap penerbitnya secara berurutan, dan baris issuer pada tiap sertifikat harus cocok dengan baris subject pada sertifikat berikutnya.

Sertifikat perantara yang hilang adalah kegagalan klasik, dan ia tidak terlihat di peramban desktop karena peramban akan mengambil sendiri sertifikat yang kurang itu atau sudah menyimpannya di cache dari situs lain. Curl, aplikasi mobile, dan klien JVM tidak melakukannya, sehingga gejalanya adalah situs yang berjalan baik bagi orang yang mengujinya tetapi gagal bagi sebagian besar trafik sungguhan.

Kalau rantainya tampak benar tetapi koneksi tetap gagal, hal berikutnya yang perlu diperiksa adalah ekstensi key usage, apakah klien memang memercayai root-nya, dan jam pada perangkat klien - perangkat dengan tanggal yang salah akan menolak sertifikat yang sepenuhnya sah dengan alasan belum berlaku.