Sertifikat SSL/TLS — Apa Arti Field dan Tanggal Kedaluwarsa yang Dijelaskan

Pada suatu saat Anda pernah memandang ikon kunci kecil di browser, mengklik “Lihat Sertifikat”, dan dihadapkan pada dinding bidang-bidang yang tampak penting namun tidak menjelaskan apa-apa: “Nama Alternatif Subjek”, “OCSP”, “SHA-256 dengan Enkripsi RSA”. Anda menutup dialog tersebut. Sertifikatnya berwarna hijau. Itu sudah cukup.

Hingga masa berlakunya habis. Pada tengah malam hari pada hari Jumat. Di lingkungan produksi.

Artikel ini menjelaskan secara rinci apa yang sebenarnya terdapat dalam sertifikat TLS — bidang demi bidang — sehingga saat Anda harus memperbaiki salah satu, Anda tahu apa yang Anda baca.

Sebuah Sertifikat Hanya Dokumen yang Telah Ditetapkan

Hapus perayaan formalitasnya, dan sertifikat TLS adalah dokumen teks yang berisi beberapa fakta — siapa pemilik domain ini, kunci publik yang digunakan, kapan dokumen ini berakhir — yang telah ditandatangani secara kriptografi oleh lembaga sertifikasi (CA). Tanda tangan CA inilah yang membuat browser mempercayainya. Semua hal lainnya hanya merupakan catatan tambahan.

Format dasarnya disebut X.509. Didefinisikan pada tahun 1988, beberapa kali diperbarui, dan saat ini ditentukan dalam RFC 5280. Itulah sebabnya dialog detail sertifikat browser terlihat seperti dirancang oleh orang-orang yang memandang tahun 1988 sebagai era baru.

Bidang-Bidang Kunci, Dijelaskan

Berikut adalah penjelasan terhadap bidang-bidang yang Anda lihat dalam sertifikat nyata. Data PEM mentah di bawah ini bersifat representatif (bukan sertifikat hidup):

Certificate:
  Data:
    Version: 3 (0x2)                          # Always v3 for modern certs
    Serial Number:                             # Unique ID issued by the CA
      04:b3:c2:...(truncated)
    Signature Algorithm: sha256WithRSAEncryption  # Hash + key algorithm used to sign
    Issuer:
      C  = US                                 # Country
      O  = Let's Encrypt                      # Organization (the CA)
      CN = R11                                # Common Name of the issuer
    Validity:
      Not Before: Apr  1 00:00:00 2026 GMT    # Cert isn't valid before this date
      Not After : Jun 30 23:59:59 2026 GMT    # Cert is invalid after this date
    Subject:
      CN = iotools.cloud                      # Domain this cert was issued for
    Subject Public Key Info:
      Public Key Algorithm: rsaEncryption
      Public-Key: (2048 bit)                  # RSA key size
    X509v3 extensions:
      Subject Alternative Names:
        DNS:iotools.cloud                     # All domains this cert covers
        DNS:www.iotools.cloud
      Key Usage: Digital Signature, Key Encipherment
      Extended Key Usage: TLS Web Server Authentication
      Basic Constraints: CA:FALSE             # This is NOT a CA cert
      Authority Key Identifier: ...           # Fingerprint of issuer's key
      Subject Key Identifier: ...             # Fingerprint of this cert's key
      Certificate Policies: ...
        CPS: http://cps.letsencrypt.org
      OCSP: http://r11.o.lencr.org           # Where to check revocation status

Nama Umum (CN)

Bidang awal untuk menentukan domain mana yang menjadi lingkup sertifikat. Anda masih akan melihatnya terisi — CN = example.com — tetapi browser sudah sebagian besar berhenti mengandalkan bidang ini. Sejak tahun 2000, ekstensi Subject Alternative Names adalah bidang yang resmi untuk pencocokan domain. CN saat ini hampir menjadi legasi; jika SAN ada, browser hanya menggunakan SAN.

Nama Alternatif Subjek (SAN)

Ini adalah daftar sebenarnya dari domain yang dilindungi oleh sertifikat. Sebuah sertifikat dapat melindungi ratusan nama — entri wildcard (*.example.com), nama eksak, bahkan alamat IP. Sertifikat multi-domain (kadang disebut sertifikat SAN atau UCC) merupakan praktik standar. CA mengeluarkan sertifikat terhadap daftar ini, dan browser membandingkan nama host yang sedang dikunjungi dengan daftar tersebut.

Satu hal yang tidak bisa dilakukan oleh wildcard adalah: melindungi sub-subdomain. mengatasi *.example.com tetapi tidak app.example.com . Banyak orang menemukan hal ini secara langsung. api.v2.example.comMasa Berlaku

Dua waktu:

Sebelum Tidak Berlaku Setelah Tidak Berlaku dan . Sertifikat tidak valid di luar jendela waktu ini — sebelum tanggal awal, setelah tanggal kedaluwarsa. Kedua waktu ini dalam waktu UTC.Masa berlaku maksimum sertifikat telah berkurang secara perlahan. Pada tahun 2015, masa berlaku maksimum adalah 3 tahun. Pada tahun 2018, ini turun menjadi 2 tahun. Pada tahun 2020, Apple secara unilateral mulai menolak sertifikat yang lebih dari 398 hari (sekitar 13 bulan), memaksa vendor browser dan CA untuk mengikuti. Pada tahun 2026, Forum CA/Browser telah menetapkan roadmap untuk mengurangi masa berlaku ini menjadi 47 hari pada tahun 2027.

Argumen untuk masa berlaku yang lebih pendek adalah masuk akal: jika kunci pribadi terkompromi, sertifikat dengan masa berlaku pendek membatasi radius kerusakan. Namun, dalam kenyataan operasional, masa berlaku yang lebih pendek menambah tekanan pada sistem otomasi perpanjangan Anda. Sertifikat 90 hari dari Let’s Encrypt pada tahun 2015 pernah kontroversial karena alasan yang sama; sekarang mereka dianggap sebagai praktik terbaik dan otomasi perpanjangan diharapkan.

Pemberi dan Rantai Kepercayaan

bidang ini menunjukkan entitas yang menandatangani sertifikat. Untuk situs publik kebanyakan, ini adalah CA intermediet (seperti R11 dari Let’s Encrypt), bukan CA akar. CA akar menandatangani sertifikat intermediet; CA intermediet menandatangani sertifikat akhir (yang ditampilkan oleh server Anda). Rantai ini ada karena kunci privat CA akar disimpan secara offline di HSM yang terisolasi, dan Anda tidak dapat mengungkapkan satu kunci untuk menandatangani jutaan sertifikat domain per tahun.

Itu Penerbit Ketika browser memvalidasi sertifikat Anda, ia bergerak ke atas rantai: sertifikat Anda → intermediet → akar. Jika akar ada di penyimpanan kepercayaan browser, rantai ini valid. Jika salah satu sertifikat dalam rantai hilang, kedaluwarsa, atau ditandatangani dengan kunci yang dibatalkan, validasi gagal.

Itulah sebabnya konfigurasi TLS paling umum adalah melupakan menyertakan sertifikat intermediet bersama sertifikat daun Anda. Browser Anda mungkin menyimpan intermediet dan tampak normal, sementara klien lain — curl, aplikasi mobile, server yang membuat panggilan API — gagal karena tidak memiliki jalur ke akar.

Algoritma Tanda Tangan

Dua hal yang dikemas dalam satu bidang: fungsi hash yang digunakan untuk mengolah data sertifikat, dan algoritma kunci yang digunakan untuk menandatangani hasil olah tersebut.

berarti hash SHA-256, tanda tangan RSA. sha256WithRSAEncryption berarti hash SHA-256, tanda tangan ECDSA. ecdsa-with-SHA256 Tanda tangan SHA-1 didekati oleh browser pada tahun 2017 dan sekarang menyebabkan kegagalan keras. Tanda tangan MD5 didekati lebih awal dan hampir punah. Jika Anda menjalankan sesuatu yang menghasilkan sertifikat SHA-1 secara internal, perbarui konfigurasi CA Anda sebelum browser pembaruan melakukannya untuk Anda.

ECDSA (umumnya P-256 atau P-384) menghasilkan kunci dan tanda tangan yang lebih kecil dibandingkan RSA untuk keamanan yang setara. Kunci EC 256 bit setara dengan kunci RSA 3072 bit. Keuntungan: RSA lebih kompatibel secara umum dengan klien lama; ECDSA lebih cepat dan lebih ringan. Pengaturan modern sering mengkonfigurasi keduanya dan membiarkan negosiasi TLS memilih.

Penggunaan Kunci dan Penggunaan Kunci yang Diperluas

Penggunaan Kunci

adalah bitmasks yang menentukan apa yang diizinkan dilakukan oleh kunci tersebut: menandatangani data, mengenkripsi data, menandatangani sertifikat lain (hanya untuk CA). Penggunaan Kunci yang Diperluas memperhalus ini untuk protokol tertentu: yang memungkinkan sertifikat digunakan untuk HTTPS. TLS Web Server Authentication untuk sertifikat klien mTLS. TLS Web Client Authentication untuk sertifikat penandatangan perangkat lunak. Code Signing Jika Anda mencoba menggunakan sertifikat untuk tujuan di luar penggunaan yang dinyatakan dalam Key Usage, implementasi TLS modern akan menolaknya. Anda tidak dapat menggunakan sertifikat penandatangan kode pada server web, bahkan jika domainnya sesuai.

Keterbatasan Dasar: CA:FALSE

Bidang ini menentukan apakah sertifikat dapat digunakan untuk menandatangani sertifikat lain.

berarti tidak — ini adalah sertifikat daun (end-entity). CA:FALSE berarti ini adalah sertifikat CA, diizinkan untuk menandatangani sertifikat lain dalam rantai. CA:TRUE yang kadang muncul bersama ini memberi tahu Anda berapa banyak CA intermediet di bawah ini yang diizinkan. CA akar sering menetapkan ini untuk membatasi kedalaman rantai.

Itu pathLenConstraint OCSP dan Pembaruan

URL OCSP (Protokol Status Sertifikat Online) dalam sertifikat memberi tahu klien di mana mereka harus memeriksa apakah sertifikat telah dibatalkan sebelum kedaluwarsa. Pembaruan terjadi ketika kunci pribadi terkompromi atau sertifikat dikeluarkan secara salah.

Dalam praktiknya, pemeriksaan OCSP oleh browser memiliki sejarah yang kompleks. Chrome berhenti melakukan pemeriksaan OCSP secara langsung bertahun-tahun lalu, beralih ke CRLSets (daftar pra-dipanggil dari sertifikat yang dibatalkan). Firefox masih melakukan OCSP tetapi secara default menggunakan soft-fail, artinya jika server OCSP tidak dapat diakses, sertifikat dianggap valid. Dampaknya: untuk kebanyakan sertifikat, pembaruan di dunia nyata hampir bersifat teoritis. Ini adalah salah satu argumen untuk sertifikat berdurasi pendek — pada 47 hari, pembaruan menjadi kurang penting karena sertifikat akan kedaluwarsa segera.

Mengapa Sertifikat Berakhir?

Kedaluwarsa bukanlah hambatan administratif. Ini adalah mekanisme yang membatasi seberapa lama kredensial yang terkompromi tetap berlaku. Alternatifnya — kredensial permanen — adalah bagaimana Anda akhirnya memiliki sertifikat SHA-1 dan kunci CA yang sudah berusia dekade yang berada di lingkungan produksi, yang hampir merupakan kondisi industri pada tahun 2010.

Kompromi operasional adalah: masa berlaku yang lebih pendek membutuhkan otomasi yang andal. Jika perpanjangan Anda bergantung pada pengingat jadwal admin, Anda akan kedaluwarsa di lingkungan produksi akhirnya. Jawaban yang tepat adalah perpanjangan otomatis melalui ACME (protokol Let’s Encrypt) atau API CA, dengan pemantauan yang memberi peringatan beberapa minggu sebelum kedaluwarsa, bukan malam hari ketika sertifikat mati.

Cara Membaca Sertifikat Tanpa Baris Perintah

Cara standar untuk memeriksa sertifikat adalah

, yang menghasilkan output yang disusun untuk orang yang menemukan bacaan RFC 5280 sebagai bahan ringan. Jika Anda ingin informasi yang sama dalam format yang tidak membutuhkan menghafal perintah openssl, maka openssl x509 -in cert.pem -text -nooutdi iotools.cloud keduanya menerima sertifikat yang dienkripsi PEM dan mengembalikan setiap bidang yang diberi label dan diatur — berguna saat Anda sedang memperbaiki masalah rantai pada tengah malam dan teks panjang dari openssl tidak membantu. Dekoder Sertifikat SSL/TLS dan Parser Sertifikat X.509 Sertifikat SSL/TLS — Arti Bidang-Bidang dan Tanggal Kedaluwarsa 2

Anda mungkin juga menyukai