Sertifikat TLS di Webship: ACME CA Tertanam

# Sertifikat TLS di Webship: ACME CA Tertanam

Sertifikat TLS melakukan dua pekerjaan: membantu mengenkripsi koneksi dan memberi tahu klien identitas siapa yang sedang diajak bicara. Enkripsi bisa kuat sementara keputusan kepercayaan salah untuk audiens. Itulah mengapa otomatisasi sertifikat harus dimulai dengan satu pertanyaan: siapa yang harus mempercayai situs ini?

Webship 1.4.0 membuat pilihan itu secara independen untuk setiap situs yang dikonfigurasi. Situs web publik dapat menggunakan sertifikat ACME yang dipercaya oleh browser, layanan internal dapat menggunakan otoritas sertifikat pribadi bawaan Webship, dan situs dengan PKI yang sudah ada dapat mempertahankan file sertifikat yang dikelola operator. Mereka semua dapat berbagi satu proses Webship tanpa berbagi satu kunci pribadi atau satu batas kepercayaan.

Empat mode sertifikat otomatis, dipilih per situs

Field certificate_mode milik setiap entri [[sites]]. Ini bukan saklar global.

| Mode | Sumber tepercaya | Kecocokan terbaik | Jalur validasi | | --- | --- | --- | --- | | per_site | Penyimpanan kepercayaan browser dan sistem operasi publik | Situs publik dengan satu nama host yang tepat | ACME publik dengan TLS-ALPN-01 | | armada | Penyimpanan kepercayaan browser publik dan sistem operasi | Set besar nama tingkat ketiga dan keempat di bawah domain terdaftar secara eksplisit | ACME publik dengan DNS-01 dan pecahan sertifikat yang stabil | | tertanam | Root Webship pribadi yang dipasang oleh operator | Layanan internal, perangkat yang dikelola, armada pribadi, dan lingkungan pengujian | Penerbitan dalam proses; tidak ada tantangan eksternal | | dibagikan | Penyimpanan tepercaya browser publik dan sistem operasi | Penempatan lama yang sengaja menggunakan satu grup multi-SAN publik | ACME publik dengan TLS-ALPN-01 |

Defaultnya adalah per_site. Ini memesan satu sertifikat publik untuk nama situs yang tepat. Mode Fleet adalah opsi publik yang dapat diskalakan untuk banyak subdomain dalam. Mode Embedded menggunakan CA pribadi dalam proses Webship. Mode Shared tetap tersedia untuk kompatibilitas, tetapi ini bukan default.

Sertifikat dan kunci lengkap di bawah [sites.tls] selalu memiliki prioritas dibandingkan penerbitan otomatis untuk situs tersebut.

Apa arti “ACME CA yang tertanam”

Bagian konfigurasi bernama [acme_ca], tetapi CA yang tertanam bukanlah layanan ACME publik atau yang dapat diakses jaringan. Ini tidak menyediakan endpoint direktori, tidak menerima pendaftaran jarak jauh, tidak memanggil API registrar, dan tidak melakukan tantangan bukti kendali.

Sebaliknya, Webship menjaga seluruh jalur penerbitan pribadi dalam satu proses:

1. Situs memilih certificate_mode = "embedded".
2. Webship memuat atau membuat identitas root pribadi di direktori status yang dikonfigurasi.
3. Webship menghasilkan kunci pribadi baru untuk situs tersebut.
4. Tanda akar yang tertanam menandatangani sertifikat daun untuk nama itu tepat.
5. Webship memvalidasi identitas yang selesai sebelum menginstalnya di pemecah TLS langsung.
6. Sertifikat itu kemudian tersedia untuk setiap protokol yang diaktifkan untuk situs tersebut.

Tantangan jaringan gaya ACME hanya akan membuktikan Webship kepada dirinya sendiri, jadi jalur yang tertanam sengaja tidak memiliki protokol jaringan. Bagian [acme_ca] adalah keadaan PKI pribadi: ini menentukan di mana root berada dan berapa lama sertifikat leaf yang diterbitkan tetap berlaku.

Konfigurasikan sertifikat tertanam untuk satu situs

Ini adalah bentuk minimal untuk situs pribadi:

~~~toml listen = "0.0.0.0:443"

[tls] unknown_sni = "tolak"

[otomatis_tls] diaktifkan = true cache_dir = "/var/lib/webship/acme"

[acme_ca] state_dir = "/var/lib/webship/acme-ca" leaf_validity_days = 90

[[situs]] domain = "service.internal.example" root = "/srv/service" certificate_mode = "tertanam"

[situs.protokol] h1 = benar h2 = benar h3 = benar ~~~

Identitas root dibuat secara malas ketika sebuah situs tertanam membutuhkannya untuk pertama kali. Webship menyimpan kunci root dengan izin terbatas di state_dir. Sertifikat root memiliki masa berlaku sepuluh tahun; masa berlaku daun dikontrol oleh leaf_validity_days.

Perlakukan kedua lokasi penyimpanan sebagai kondisi produksi:

• Cache ACME menyimpan identitas situs yang dikelola secara otomatis.
• Direktori status embedded-CA menyimpan identitas root pribadi.
• Akun layanan memerlukan akses, tetapi pengguna aplikasi tidak.
• Cadangan harus menjaga kerahasiaan dan izin file.
• Produksi, pengembangan, dan pengujian sebaiknya menggunakan root dan direktori yang terpisah.

Menghapus direktori root tidak 'mengatur ulang TLS.' Ini membuat jangkar kepercayaan baru. Klien yang mempercayai root lama akan menolak sertifikat yang diterbitkan oleh pengganti sampai penyimpanan kepercayaan mereka diperbarui.

Kepercayaan pribadi adalah disengaja

Sertifikat dari CA yang tertanam tidak otomatis dipercaya oleh browser publik atau sistem operasi. Mereka menjadi terpercaya hanya setelah operator menginstal sertifikat root Webship yang diekspor di penyimpanan kepercayaan klien.

Itu menjadikan mode tertanam cocok untuk:

• laptop dan ponsel yang dikelola perusahaan yang terdaftar melalui manajemen perangkat;
• lalu lintas internal antar layanan dengan bundel CA yang eksplisit;
• peralatan pribadi dan armada tepi yang dikendalikan;
• lingkungan pengembangan dan pengujian yang harus menjalankan perilaku TLS yang nyata;
• jaringan yang terputus yang tidak dapat bergantung pada CA publik.

Ini bukan mode yang tepat untuk situs web publik biasa yang pengunjungnya menggunakan browser yang tidak dikelola. Gunakan penerbitan per_site publik untuk nama publik yang tepat, penerbitan fleet untuk set subdomain publik besar, shared hanya untuk implementasi multi-SAN warisan yang disengaja, atau file manual dari PKI yang sudah dipercaya.

Distribusikan hanya sertifikat root ke klien. Jangan pernah mendistribusikan kunci privat root. Kepemilikan kunci itu memberikan wewenang kepada pemegangnya untuk menerbitkan identitas yang dipercaya oleh setiap klien yang terdaftar.

Sertifikat publik dan privat dapat hidup berdampingan

Webship 1.4.0 dapat mencampur strategi sertifikat pada pendengar yang sama:

~~~toml listen = "0.0.0.0:443"

[tls] unknown_sni = "tolak"

[tls_otomatis] diaktifkan = benar directory_url = "https://acme-v02.api.letsencrypt.org/directory" cache_dir = "/var/lib/webship/acme" kontak = ["mailto:ops@example.com"] terima_syarat_layanan = true

[acme_ca] state_dir = "/var/lib/webship/acme-ca" leaf_validity_days = 90

[[situs]] domain = "www.example.com" root = "/srv/public" certificate_mode = "per_site"

[[situs]] domain = "control.internal.example" root = "/srv/control" certificate_mode = "tertanam"

[[situs]] domain = "payments.example.com" root = "/srv/payments"

[situs.tls] cert = "/etc/webship/payments-fullchain.pem" kunci = "/etc/webship/payments-private-key.pem" ~~~

Di sini, www.example.com menerima sertifikat ACME publiknya sendiri. control.internal.example menerima sertifikat pribadi dari CA yang tertanam. payments.example.com tetap berada di bawah PKI eksternal operator karena file eksplisitnya lebih diutamakan.

Direktori publik ACME diabaikan oleh situs tertanam. Root tertanam tidak pernah menandatangani situs publik. Situs manual tidak pernah secara diam-diam terdaftar ke dalam salah satu alur kerja otomatis.

Satu penyelesai sertifikat untuk H1, H2, H3, dan WebTransport

Pemilihan sertifikat terjadi selama handshake TLS, sebelum permintaan HTTP ada. Webship menggunakan nama server ClientHello untuk memilih identitas situs dan kemudian menegosiasikan protokol aplikasi.

• HTTP/1.1 dan HTTP/2 menggunakan TLS melalui TCP.
• HTTP/3 dan WebTransport menggunakan TLS di dalam QUIC melalui UDP.
• Satu identitas situs yang valid dapat melayani setiap protokol yang diaktifkan.
• HTTP/3 juga memerlukan keterjangkauan UDP; H1 dan H2 menggunakan jalur TCP.
• Alt-Svc dapat mengiklankan H3 sambil mempertahankan fallback TCP.

TCP, TLS, dan QUIC menggunakan model identitas yang sama yang menyadari situs. Nama yang tepat memiliki prioritas, wildcard valid terpanjang menang di mana sertifikat wildcard dikonfigurasi, dan SNI dengan nama yang tidak dikenal dapat ditolak alih-alih menerima sertifikat default yang tidak terkait.

Gunakan unknown_sni = "reject" pada listener multi-situs ketika hostname yang tidak dikenali harus gagal tertutup. Uji nama yang dikenali, nama yang tidak dikenali, dan perilaku no-SNI yang Anda harapkan sebelum peluncuran produksi.

Memutar identitas yang tertanam tanpa celah penyajian

Webship menampilkan status sertifikat dan mutasi yang dikontrol melalui server MCP yang diautentikasi dan terikat loopback:

• webship.tls.get_status melaporkan resolver sertifikat aktif dan status pembaruan.
• webship.tls.reissue_certificate segera mengeluarkan ulang sertifikat yang dikelola secara otomatis hanya ketika situs tersebut menggunakan mode tertanam.
• webship.tls.reload memuat ulang status sertifikat melalui jalur TLS yang dijaga secara normal.
• webship.acme_ca.status melaporkan apakah CA pribadi dipilih, direktori keadaannya, masa hidup leaf, jumlah penerbitan, jumlah pencabutan, dan contoh domain terbaru.
• webship.sites.apply menambahkan atau menghapus situs terhadap versi konfigurasi yang dipasang.

Untuk penerbitan ulang yang tertanam, Webship membuat dan memvalidasi pengganti sebelum menukarnya ke dalam layanan. Identitas yang berlaku saat ini terus melayani sampai identitas baru siap. Identitas yang dipensiunkan dicatat hanya setelah pengganti diinstal.

Operasi penerbitan ulang segera secara sengaja menolak sertifikat per_site publik. Pembaruan publik harus tetap berada di dalam siklus hidup ACME publik daripada bingung dengan penandatanganan proses privat. Keanggotaan mode-berbagi juga dibekukan ulang karena mengubah grup multi-SAN membangun kembali batas identitas.

MCP adalah permukaan kontrol istimewa. Jaga dalam loopback, gunakan TLS dan token bearer yang kuat, gunakan terowongan yang diautentikasi untuk administrasi jarak jauh, dan audit setiap perubahan.

Batas kegagalan yang penting

Sistem sertifikat yang aman harus gagal ke arah yang benar.

• Situs tertanam yang baru dikonfigurasi tidak menerima identitas situs lain saat penerbitan sedang menunggu.
• Penggantian yang tidak valid tidak dipasang di atas sertifikat yang berfungsi.
• File manual eksplisit mencegah kepemilikan otomatis situs tersebut.
• SNI yang tidak dikenal dapat ditolak sebelum routing HTTP.
• CA yang tertanam tetap bersifat pribadi dan tidak memiliki titik akhir pendaftaran jarak jauh.
• Identitas publik dan tertanam menggunakan jalur cache terpisah di dalam status TLS-otomatis.

Peringatan bahwa CA yang tertanam tidak diinisialisasi berarti Webship tidak dapat mengaktifkan direktori status yang dikonfigurasi. Perbaiki kepemilikan, izin, ketahanan, atau ketersediaan penyimpanan sebelum mengirim lalu lintas ke situs yang terdampak. Jangan mengatasi kesalahan ini dengan menyalin kunci root dari lingkungan lain.

Daftar periksa produksi

Sebelum mengaktifkan mode tertanam:

1. Identifikasi setiap populasi klien yang harus mempercayai situs tersebut.
2. Buat proses yang terkontrol untuk mengekspor dan menginstal sertifikat root.
3. Gunakan state root terpisah untuk produksi, pengembangan, dan pengujian.
4. Pertahankan dan lindungi direktori status CA-tertanam dan cache TLS otomatis.
5. Jalankan Webship di bawah akun layanan khusus yang hanya memiliki akses ke materi kunci yang diperlukan.
6. Pilih certificate_mode di setiap situs yang batas kepercayaannya harus eksplisit.
7. Tetapkan dan uji kebijakan SNI yang tidak diketahui.
8. Aktifkan H1, H2, dan H3 dengan sengaja dan verifikasi jalur TCP serta UDP.
9. Latih penerbitan ulang, mulai ulang, cadangan, pemulihan, dan validasi kepercayaan klien di luar produksi.
10. Jalankan webship --check-config sebelum peluncuran, lalu verifikasi penerbit, nama, validitas, rantai, dan protokol yang dinegosiasikan dari klien nyata.

Pilih kepercayaan terlebih dahulu, otomatisasi kedua

CA terbenam menghilangkan ketergantungan layanan sertifikat eksternal untuk infrastruktur pribadi. Ini tidak membuat root pribadi dipercaya secara global, dan ini tidak menghapus tanggung jawab PKI operator.

Webship mengotomatiskan pembuatan kunci, penandatanganan, validasi, instalasi, rotasi, dan pemilihan sertifikat di seluruh protokol. Operator tetap memiliki kepemilikan root, pendaftaran klien, pemisahan lingkungan, cadangan, pemulihan, dan keputusan untuk menggunakan jalur kepercayaan publik atau pribadi.

Pemutusan itu adalah fiturnya. Sebuah server mandiri dapat mengotomatiskan TLS pribadi tanpa berpura-pura menjadi CA publik—dan situs publik masih dapat menggunakan penerbitan per-situs atau armada yang dipercaya browser dalam proses yang sama.

Baca dokumentasi Webship 1.4.0 yang memiliki versi sebelum peluncuran. RFC 5280 mendefinisikan profil sertifikat dan validasi, RFC 6066 mendefinisikan sinyal nama server TLS, RFC 8446 mendefinisikan TLS 1.3, RFC 8555 mendefinisikan ACME publik, dan RFC 9525 mendefinisikan verifikasi identitas layanan.