Let's Encrypt, Bersiap Menerbitkan Sertifikat Alamat IP

 (community.letsencrypt.org)
7 poin oleh GN⁺ 2025-06-27 | 1 komentar | Bagikan ke WhatsApp
  • Let's Encrypt akan segera mendukung penerbitan sertifikat yang mencakup SAN alamat IP, dan pada tahap awal hanya akan tersedia untuk profil shortlived dengan masa berlaku 6 hari, serta akan dioperasikan secara terbatas dengan sistem whitelist untuk sementara waktu
  • Sebelum peluncuran resmi, belum ada jadwal rinci maupun panduan pendaftaran, dan pengujian internal serta persiapan masih berlangsung
  • Di lingkungan staging, sertifikat contoh yang mencakup alamat IPv6 beserta situs yang menerapkannya telah dipublikasikan, dan komunitas diminta membagikan temuan anomali atau masukan
  • Bug terkait tampilan IP SAN di Firefox (BZ #1973855) telah ditemukan dan pengujian masih berlanjut
  • Potensi kebingungan pada kasus campuran DNS SAN dan IP SAN telah dikonfirmasi melalui contoh pengujian nyata, menunjukkan bahwa penulisan TLD dan alamat IPv6 bisa tampak mirip

Let's Encrypt, Getting ready to issue IP address certificates

Status persiapan dukungan IP address SAN

  • Let's Encrypt berencana segera mendukung penerbitan sertifikat yang mencakup IP address SAN di lingkungan produksi
  • Sertifikat tersebut hanya akan diterbitkan melalui profil shortlived dengan masa berlaku 6 hari, dan untuk sementara akan dioperasikan secara terbatas dengan metode allowlist
  • Jadwal rilis resmi dan cara mengajukan allowlist masih belum ditetapkan, karena masih diperlukan persiapan internal tambahan

Pengujian dan sertifikat contoh

  • Contoh sertifikat yang mencakup IP SAN dan situs yang benar-benar menerapkannya (alamat IPv6) telah dipublikasikan di lingkungan staging
  • Pengguna komunitas diminta untuk membagikan temuan jika menemukan hal yang aneh, menarik, atau bermasalah

Kasus campuran IP SAN dan DNS SAN

  • Dalam proses pengujian, didemonstrasikan kemungkinan penerbitan sertifikat yang sekaligus mencakup DNS SAN dan IP SAN serta contoh kebingungan pada tampilannya
  • Ada potensi kebingungan karena penulisan TLD tertentu seperti .cafe dapat tampak mirip dengan alamat IPv6
  • Bug Firefox terkait tampilan IP address SAN (BZ #1973855) juga telah dikonfirmasi

Ringkasan

  • Dukungan sertifikat alamat IP dari Let's Encrypt pada awalnya akan diterapkan secara terbatas melalui whitelist dan sertifikat jangka pendek
  • Sebelum diterapkan ke layanan nyata, berbagai skenario pengujian dan masukan komunitas akan digunakan untuk memeriksa stabilitas dan kompatibilitas
  • Isu tampilan browser akibat penggunaan campuran SAN nama DNS dan alamat IP juga sedang dibahas bersama

Bacaan terkait

1 komentar

 
GN⁺ 2025-06-27
Komentar Hacker News

  • Menurut saya sertifikat untuk alamat IP juga berguna
    Namun saya rasa dampaknya akan jauh lebih besar jika Let‘s Encrypt mendukung sertifikat S/MIME
    Sudah bertahun-tahun ada situasi yang agak konyol terkait enkripsi email
    Sekarang sebagian besar klien email utama sudah langsung mendukung enkripsi S/MIME, tetapi seperti web, untuk pengalaman pengguna yang mulus tetap perlu mendapatkan sertifikat dari CA
    CA yang tepercaya, gratis, dan menyediakan sertifikat S/MIME dengan masa berlaku lebih dari 1 tahun kini sudah tidak ada lagi
    Akibatnya, pengguna individu praktis tidak memakai enkripsi email sama sekali
    PGP terlalu merepotkan sehingga hampir tidak dipakai selain oleh para penggemar teknis
    Menurut saya sekarang kita juga harus mengenkripsi email kita
    Sebagai catatan, jika CA membuatkan kunci privat untuk kita, saya menganggap sertifikat itu tidak dapat dipercaya
    Selain itu, karena S/MIME mengharuskan sertifikat lama tetap disimpan untuk mendekripsi email lama, sertifikat yang terlalu sering berganti jadi tidak praktis

    • Terkait pernyataan bahwa sertifikat lama diperlukan untuk mendekripsi email lama di S/MIME, menurut saya tidak harus sering diganti karena kunci dekripsi itu sendiri bisa dipakai lagi saat membuat sertifikat baru (misalnya dengan opsi --reuse-key di certbot)
      Apakah cara ini merupakan praktik yang baik adalah persoalan terpisah
      Yang benar-benar dibutuhkan menurut saya adalah otomasi penerbitan sertifikat bergaya ACME
      Saat ini proses perpanjangan sertifikat terlalu merepotkan sehingga hampir tidak dipakai

    • PGP sekarang punya metode bernama WKD (Web Key Directory)tautan yang memungkinkan web kepercayaan TLS diterapkan ke email
      Sertifikat TLS jauh lebih mudah diperoleh daripada sertifikat S/MIME
      Manajemen identitas oleh pihak ketiga bisa membantu, tetapi kebanyakan orang bekerja di perusahaan yang kurang cocok dengan model seperti itu
      Kalau untuk perusahaan, menurut saya lebih tepat jika manajemen identitas dilakukan secara internal
      Insiden Signalgate 1.0 baru-baru initautan menurut saya sangat memberi pelajaran karena menunjukkan kegagalan manajemen identitas dalam enkripsi ujung-ke-ujung
      Hal seperti ini membuat saya berpikir bahwa jika sertifikat S/MIME atau WKD benar-benar diadopsi sebagai sistem yang layak pakai, itu juga bisa berguna bagi pemerintah

    • Secara pribadi saya cukup optimistis terhadap email terenkripsi berbasis S/MIME, tetapi merasa kemungkinan terwujudnya rendah
      Pengguna umum sering kesulitan bahkan untuk mengelola kunci privat, dan kenyataannya bahkan kata sandi email saja sering tidak dikelola dengan baik
      Pada akhirnya akan muncul situasi di mana penerbitan sertifikat perlu dipusatkan per domain, atau pengguna tidak bisa mendapatkan sertifikat sama sekali, sementara penjahat siber mengirim email bertanda tangan S/MIME
      Jika ke depan penggunaan passkey sudah umum dan terjadi pergantian generasi, menurut saya barulah tepat mendorong orang mengelola pasangan kunci sendiri

    • Ada pendapat bahwa enkripsi email sebaiknya memang hilang saja
      Referensi: Stop using encrypted email

    • Saya kurang paham soal enkripsi S/MIME, jadi ada yang ingin saya tanyakan
      Kenapa email lama harus didekripsi dengan protokol yang sama?
      Secara pribadi saya menganggap sertifikat itu untuk transport, dan untuk penyimpanan mestinya sudah ada enkripsi tersendiri di server atau host, jadi tampaknya logis kalau saat transmisi memakai sertifikat jangka pendek, lalu saat penyimpanan memakai metode enkripsi lain sesuai kebutuhan; saya penasaran apakah ada hal yang saya lewatkan

  • Saya penasaran apakah semua lembaga pengelola alamat, misalnya ISP dan penyedia cloud, juga akan ikut arus ini
    Mereka kadang merotasi IP sangat cepat, bahkan bisa lebih cepat dari 6 hari
    Saya bisa memahaminya bila penyedia cloud menerapkan masa cooldown sebelum analisis IP atau memeriksa serta mencabut sertifikat yang terkait dengan IP itu, tetapi jika tidak, kompleksitasnya akan dibebankan ke pengguna untuk memverifikasi header host dan menolak koneksi berbasis IP yang tidak diinginkan, atau menunggu sampai sertifikat lama benar-benar hilang
    Saya juga penasaran berapa banyak sertifikat IP yang bisa didapat dan berapa biayanya di masing-masing penyedia cloud

    • Sebenarnya menurut saya masalah ini tidak jauh berbeda dari penyediaan domain kustom/vanity oleh penyedia cloud
      Misalnya di Azure, DNS seperti myapp.westus.cloudapp.azure.com bisa dihubungkan ke VM, dan siapa pun bisa mendapatkan sertifikat untuk domain itu dari CA referensi
      Dalam kasus seperti ini juga, tanpa cooldown khusus, saat VM dihapus orang lain bisa langsung mengambil domain itu

    • Sertifikat HTTPS bisa diperpanjang untuk 90 hari satu hari sebelum domain kedaluwarsa, dan CA juga tidak tahu batas kartu pembayaran
      Orang yang akan memakai sertifikat IP kemungkinan besar bukan tipe pengguna yang cepat membuang IP lalu pergi begitu saja
      Kasus yang paling berguna adalah perangkat lunak lama yang sangat khusus, atau kebutuhan dukungan ECH (Encrypted Client Hello) maupun ESNI (Encrypted SNI) tanpa IP bersama seperti pada Cloudflare
      Untuk kasus pertama (legacy), mereka tidak akan mudah melepas IP-nya, dan untuk kasus kedua (ECH/ESNI), saya rasa akan sulit benar-benar berhasil tersambung ke domain aslinya

    • Untuk pertanyaan apakah ISP harus ikut serta, saya justru melihatnya dari arah sebaliknya
      Peran ISP bukan mengalokasikan IP dengan cara yang sesuai standar TLS, melainkan penyedia sertifikat TLS yang harus berperan melakukan "verifikasi identitas" sesuai cara ekosistem menghubungkan identitas seperti domain dan IP
      Belum dijelaskan rinci bagaimana pendekatannya kali ini, tetapi firasat saya LetsEncrypt akan membuat daftar IP yang memang dipindahkan dalam jangka panjang berdasarkan ASN (Autonomous System Number), mungkin dikelola bersama seperti database publik semacam Mozilla Public Suffix List, lalu hanya menerbitkan sertifikat untuk IP dalam daftar itu, dan jika pindah ke ASN lain maka akan ada pengelolaan pencabutan sertifikat
      Saya berharap mekanismenya juga dibagikan dengan penerbit ACME lain

    • Jika penasaran berapa banyak sertifikat IP yang bisa didapat dan berapa biayanya di berbagai cloud, saya juga penasaran apakah nantinya akan ada dukungan sertifikat wildcard

    • Dalam situasi saya, memiliki sertifikat IP bahkan hanya untuk satu hari saja sudah cukup untuk menguji URL https, jadi menurut saya ini perubahan yang sangat disambut baik

  • Secara teknis saya paham cara kerjanya, tetapi penasaran apa sebenarnya kasus penggunaan yang dimaksud

    • Dukungan ECH (Encrypted Client Hello) atau ESNI (Encrypted SNI) saja menurut saya sudah sangat berarti
      Pada awal ESNI, hanya proxy https besar seperti Cloudflare yang bisa menerapkannya sehingga adopsi sertifikat IP terdengar seperti ide impian, tetapi sekarang semua server bisa ikut dalam ESNI/ECH
      Jika klien mulai mencoba ESNI dengan asumsi semua server punya sertifikat IP, ini berpotensi sangat membantu peningkatan privasi di seluruh internet

    • Banyak contoh bagus sudah muncul di berbagai balasan, tetapi NTS (Network Time Security) juga layak disebut
      Tanpa sertifikat IP, NTS juga membutuhkan DNS, sehingga jika DNS mati maka sinkronisasi waktu terautentikasi menjadi sama sekali tidak mungkin
      DNSSEC gagal divalidasi jika waktunya tidak benar, jadi kalau bergantung pada DNS+NTS maka pemulihannya buntu
      Jika sertifikat yang memuat IP memungkinkan distribusi waktu terautentikasi tanpa DNS, masalah ini bisa diselesaikan

    • Jika Anda perlu mempertahankan sertifikat yang tetap valid saat DNS sedang banyak berubah, misalnya untuk memastikan akses ke dashboard atau agar otomasi lama tidak berhenti karena kesalahan DNS, ini bisa dipakai
      Contoh lain adalah menyiapkan lingkungan uji secara langsung dengan lebih sederhana tanpa perlu DNS, atau mengekspos layanan seperti Cockpit ke luar dengan cepat
      Pada dasarnya muncul banyak kemungkinan penggunaan sejauh imajinasi memungkinkan

    • Ini juga bisa menjadi pendekatan yang menarik untuk DoTLS oportunistik terhadap authdns (server DNS otoritatif)
      Server DNS otoritatif bisa melayani di port DoTLS dengan sertifikat yang menyertakan IP publik sebagai SAN (Subject Alternative Name)
      Saat ini hal itu juga bisa dilakukan dengan hostname, tetapi karena satu IP publik bisa memiliki banyak nama berbeda, SAN berbasis IP mengikatnya dengan lebih jelas

    • Menurut saya ini cocok bagi orang yang ingin langsung menghubungkan proyek ke IP alih-alih hostname, misalnya untuk hobi atau keperluan sekali pakai tanpa domain

  • Saya penasaran kenapa sertifikat tidak diterbitkan oleh registri internet regional (RIR) atau registri lokal (LIR)
    Mengapa pihak ketiga harus memverifikasi pendaftar RIR dan LIR, apakah karena registrar domain sudah terlalu banyak pekerjaan
    Saya penasaran apakah alasannya sama

  • Rasanya seperti menambah celah baru untuk menyalahgunakan TLS
    Sebelumnya masalahnya adalah menerbitkan sertifikat untuk domain yang tidak dimiliki, sekarang bisa saja muncul sertifikat untuk IP yang tidak dimiliki
    Para black hat pasti sedang ramai membahasnya di Telegram

    • Sebenarnya sertifikat IP sudah ada sejak dulu; yang berubah hanya sekarang Let's Encrypt juga menyediakannya

  • Saya penasaran apakah ini berarti halaman admin router lokal, misalnya 192.168.0.1, bisa diakses lewat https tanpa error self-signed

    • Tidak bisa, tetapi mungkin suatu saat bisa
      Alamat lokal tidak dialokasikan secara universal dan juga tidak dirutekan secara global, jadi pada dasarnya tidak ada cara untuk memverifikasinya
      Namun jika produsen router memang mau, pada perangkat yang tidak berada di belakang CG-NAT dan mendapat alamat IPv4 publik, mereka bisa meminta sertifikat untuk alamat publik tersebut
      Untuk IPv6 saya rasa lebih mudah lagi karena kebanyakan memang dirutekan secara global

    • Tidak bisa, dan memang seharusnya begitu
      Pada praktiknya, dengan menggabungkan proxy, domain sungguhan, sertifikat asli, dan fungsi rewrite DNS, hal itu sudah cukup memungkinkan
      Misalnya memakai UI manager nginx dan adguard sebagai DNS
      Batasi DNS router ke adguard, lalu rewrite domain saya ke proxy
      Daftarkan domain dan terbitkan sertifikat asli, beres
      Saya sendiri memakai https untuk semua layanan lokal saya

    • Sertifikat tidak diterbitkan untuk IP privat
      IP privat yang sama bisa merujuk ke perangkat yang sama sekali berbeda di jaringan lain, sehingga kepemilikan eksklusif tidak bisa dijamin

    • Justru sebaliknya
      Jika bukan IP publik, sertifikat yang valid tidak bisa diterbitkan
      Sudah ada cara dengan mendapatkan sertifikat domain lalu meneruskan domain itu ke 192.168.0.1

    • Untuk mendapatkan sertifikat, Anda memang harus benar-benar memiliki IP tersebut (IP publik)

  • Saya penasaran apakah sertifikat untuk IPv4 internal (192.168.x.x, 172.16.x.x, 10.x.x.x) juga mungkin, atau memang browser sebaiknya mengabaikan alamat seperti itu, dan kalau tidak, apakah setidaknya bisa mendapatkan sertifikat wildcard untuk jaringan internal

    • Dalam konteks sertifikat yang diterbitkan oleh CA publik, menurut saya pertanyaan itu tidak terlalu masuk akal
      Berbeda dengan domain, IP privat seperti 10.10.10.10 "dimiliki" banyak orang pada saat yang sama
      Untuk pengembangan internal ada alat seperti mkcert, dan untuk sumber daya internal perusahaan, sertifikat TLS berbasis domain lebih praktis

    • Jika Anda bisa membuktikan bahwa kunci privat perangkat benar-benar tidak akan pernah bocor, mungkin ini masih bisa dicoba dengan CA yang ada
      Namun untuk sertifikat alamat internal, jika seseorang membeli perangkat lalu mengekstrak kunci privatnya, pencabutan kunci sertifikat langsung menjadi masalah
      Karena itu, untuk perangkat tepercaya lebih realistis mengimpor sertifikat secara manual agar bisa diakses tanpa error, atau jika perangkatnya banyak, membangun CA sendiri untuk mendistribusikan sertifikat
      Dengan server ACME open source, otomasi penerbitan ala Let's Encrypt juga bisa dijalankan secara internal

    • Atur DNS agar awalnya menunjuk ke server publik untuk mendapatkan sertifikat, lalu setelah itu turunkan DNS ke alamat internal 192.168… dan salin sertifikat serta kuncinya
      Yang perlu diperhatikan, beberapa router bisa mem-blackhole respons DNS yang diarahkan ke alamat internal, jadi perlu diuji terlebih dahulu

    • Menurut saya browser tidak seharusnya mengabaikan jaringan privat
      Bagi saya, jaringan privat mungkin cuma router lokal di rumah, tetapi bagi orang lain bisa saja itu jaringan yang mencakup seluruh dunia

  • Menarik bahwa sertifikat contohnya tidak memiliki field subject
    Saya penasaran apakah itu karena permintaannya menggunakan IP dan DNS dicantumkan di SAN

    • Menurut tim Let's Encrypt, ke depan mereka berencana hanya memakai subject alternative names alih-alih subject common name
      Ini sudah diterapkan pada profil sertifikat jangka pendek 6 hari, tetapi belum pada profil "klasik" 90 hari

  • Disebut sambil bercanda, apakah ini saatnya kerentanan CVE-2010-3170 kembali mencuat

    • Jika Anda mengimplementasikan sendiri logika verifikasi X.509, kerentanan seperti itu mungkin masih tersisa, tetapi untuk benar-benar mengeksploitasinya, CA yang salah perilaku harus menerbitkan sertifikat terkait, jadi menurut saya kemungkinannya rendah

  • Sayangnya, sertifikat untuk alamat IP tidak bisa diterbitkan dengan metode DNS challenge
    Tetapi saya paham alasannya