Cara Jana Sijil Wildcard Certbot Menggunakan DNS-01

Mengapa sijil wildcard memerlukan DNS-01

Sijil wildcard melindungi setiap subdomain peringkat pertama bagi sesuatu domain: *.example.com memadankan app.example.com, blog.example.com, dan sebarang nama lain yang mempunyai satu label. Let’s Encrypt mengeluarkan sijil wildcard hanya melalui cabaran DNS-01, jadi Certbot perlu membuktikan kawalan ke atas DNS domain tersebut dengan menerbitkan rekod TXT pada _acme-challenge.example.com. Cabaran HTTP-01 tidak layak digunakan, kerana menghidangkan fail token hanya membuktikan kawalan ke atas satu nama hos, iaitu hos yang daripadanya pelayan pengesahan mengambil fail tersebut. Sijil wildcard merupakan tuntutan ke atas setiap nama yang mungkin di bawah domain tersebut, dan satu-satunya rekod awam yang mewakili keseluruhan ruang nama ialah DNS itu sendiri.

Keperluan tunggal itu menentukan segala-galanya di halaman ini. Untuk melepasi DNS-01, anda mesti mampu mencipta rekod TXT dalam zon domain tersebut, sama ada secara manual atau melalui API (antara muka pengaturcaraan aplikasi) pembekal DNS anda. Kaedah manual hanya berkesan sekali dan kemudian gagal semasa pembaharuan, atas sebab konkrit yang ditunjukkan di bawah. Kaedah API, melalui pemalam DNS Certbot, melakukan pembaharuan tanpa pengawasan, dan ia merupakan persediaan yang harus anda gunakan sebagai penyelesaian akhir.

Ini adalah bab wildcard bagi panduan Certbot kami. Sijil nama hos tunggal biasa, konfigurasi pelayan web dan peraturan port 80 diliputi dalam Certbot dengan nginx pada Ubuntu 24.04 dan Certbot dengan Apache pada Ubuntu 24.04.

Bagaimana rekod TXT _acme-challenge berfungsi

Apabila Certbot meminta *.example.com, Let's Encrypt membalas dengan token rawak. Certbot menggabungkan token tersebut dengan kunci akaun ACME (automatic certificate management environment) anda, melakukan hashing terhadap hasil tersebut menggunakan SHA-256, dan menghasilkan nilai teks yang pendek. Nilai tersebut mesti muncul sebagai rekod TXT pada _acme-challenge.example.com. Seterusnya, Let's Encrypt akan membuat pertanyaan kepada pelayan nama autoritatif domain anda daripada infrastruktur mereka sendiri. Jika rekod yang dibaca sepadan dengan nilai yang dijangkakan, anda telah membuktikan bahawa anda mengawal zon tersebut, dan kawalan terhadap zon itu diterima sebagai bukti kawalan ke atas setiap nama di bawahnya.

Dua perincian sering menyebabkan kegagalan:

• Meminta example.com dan *.example.com pada sijil yang sama bermakna dua cabaran berasingan, dan kedua-dua rekod TXT tersebut berada pada nama yang sama, iaitu _acme-challenge.example.com. Kedua-duanya mesti wujud pada masa yang sama. Menambah rekod kedua adalah tindakan yang betul; menggantikan rekod pertama dengan rekod kedua akan menyebabkan cabaran pertama gagal.
• Pengesahan membaca pelayan autoritatif anda, namun panel kawalan pembekal mungkin mengambil masa seminit atau lebih untuk menolak rekod baharu ke pelayan tersebut. Lakukan semakan dari luar sebelum anda membiarkan pengesahan dijalankan:

dig +short TXT _acme-challenge.example.com @1.1.1.1

Apabila arahan tersebut memaparkan nilai yang diminta oleh Certbot, pengesahan boleh berjaya. Apabila ia tidak memaparkan apa-apa, tunggu sebentar dan jalankan semula arahan tersebut.

Lihat ia berfungsi sekali: mod manual

Mod manual memaksa anda melakukan suntingan DNS sendiri, yang merupakan cara terbaik untuk memahami mekanismenya sebelum anda mengautomasikannya:

sudo certbot certonly --manual --preferred-challenges dns -d example.com -d '*.example.com'

Tanda petikan di sekeliling wildcard menghalang shell anda daripada menganggap * sebagai corak nama fail. Certbot berhenti seketika dengan arahan:

Please deploy a DNS TXT record under the name:
_acme-challenge.example.com.
with the following value:
Jx9mQ2wLr8vTn5cKp0aYdG3hB7fZs4eN1oiRuXqMk6E

Cipta rekod TXT tersebut dalam panel pembekal DNS anda, sahkan ia boleh dilihat dengan arahan dig di atas, dan hanya selepas itu tekan Enter. Kerana larian ini meminta domain asas dan wildcard, Certbot akan meminta dua kali; kekalkan kedua-dua rekod di tempatnya sehingga pengeluaran sijil selesai. Kejayaan berakhir dengan baris yang biasa dilihat:

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/example.com/fullchain.pem

Mengapa mod manual tidak boleh diperbaharui secara automatik

Setiap pembaharuan merupakan cabaran baharu dengan token baharu, jadi nilai TXT berubah setiap kali. Rekod yang anda tampal hari ini tidak berguna dalam tempoh 60 hari. Pemasa pembaharuan menjalankan Certbot tanpa pengawasan sebanyak dua kali sehari, dan tiada sesiapa yang berada di papan kekunci untuk menampal nilai baharu tersebut, jadi sijil yang dikeluarkan secara manual akan gagal diperbaharui dengan ralat tepat ini:

Failed to renew certificate example.com with error: The manual plugin is not
working; there may be problems with your existing configuration.
The error was: PluginError('An authentication script must be provided with
--manual-auth-hook when using the manual plugin non-interactively.')

Anda boleh memenuhi keperluan tersebut dengan menulis skrip --manual-auth-hook yang memanggil API pembekal DNS anda, tetapi pada tahap itu anda sebenarnya sedang membina semula pemalam DNS secara manual. Gunakan mod manual untuk mempelajari aliran kerja, atau untuk kegunaan sekali sahaja yang tulen pada domain yang DNS-nya belum boleh diautomasikan, dan tetapkan peringatan sebelum hari ke-90, kerana Let's Encrypt tidak lagi menghantar e-mel tamat tempoh. Untuk segala perkara lain, gunakan pemalam.

Laluan pemalam: certbot-dns-cloudflare pada Ubuntu 24.04

Pemalam DNS menyimpan kelayakan API untuk pembekal DNS anda dan melaksanakan keseluruhan proses rekod TXT secara automatik, semasa pengeluaran sijil dan setiap kali pembaharuan. Cloudflare digunakan sebagai contoh di sini kerana ia merupakan pemalam pembekal yang paling diperlukan oleh pengguna, dan ia tersedia dalam pakej Ubuntu.

Panduan Certbot kami mengesyorkan penggunaan pakej apt pada Ubuntu 24.04, dan pendirian ini juga terpakai untuk Cloudflare:

sudo apt update
sudo apt install certbot python3-certbot-dns-cloudflare

Satu nota jujur mengenai versi. Arkib 24.04 membekalkan pemalam ini pada versi 2.0.0 bersama Certbot 2.9.0; apt policy python3-certbot-dns-cloudflare menunjukkan versi anda. Ketidakpadanan ini tidak mendatangkan masalah, dan token API berlingkup (scoped) berfungsi kerana pustaka python3-cloudflare asas dalam 24.04 adalah 2.11.1, iaitu melebihi versi 2.3.1 yang diperlukan oleh pemalam untuk sokongan token. Pada keluaran Ubuntu yang lebih lama, pustaka tersebut terlalu lama untuk menyokong token, yang menjadi punca amaran yang mungkin anda temui dalam talian mengenai pemalam apt yang memaksa penggunaan Global API Key. Pada 24.04, perkara ini tidak lagi terpakai.

Dalam papan pemuka Cloudflare, cipta token API berlingkup, bukan Global API Key: pergi ke My Profile, kemudian API Tokens, seterusnya Create Token, dengan kebenaran tunggal Zone / DNS / Edit, yang dihadkan kepada satu zon yang anda ingin keluarkan sijilnya. Simpan token tersebut dalam fail yang hanya boleh dibaca oleh root:

sudo mkdir -p /root/.secrets
sudo tee /root/.secrets/cloudflare.ini > /dev/null <<'EOF'
dns_cloudflare_api_token = paste_your_scoped_token_here
EOF
sudo chmod 600 /root/.secrets/cloudflare.ini

Certbot menyemak mod fail dan akan memberi amaran tentang Unsafe permissions on credentials configuration file jika fail tersebut boleh dibaca oleh pengguna lain. Sekarang, jalankan arahan:

sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/cloudflare.ini \
  -d example.com -d '*.example.com'

Pemalam ini mencipta rekod TXT melalui API, menunggu tempoh penyebaran (propagation delay) yang singkat, membenarkan pengesahan dijalankan, kemudian memadamkan rekod tersebut semula. Jika pelayan nama zon anda lambat mengemas kini perubahan, tingkatkan tempoh menunggu dengan --dns-cloudflare-propagation-seconds 60. Sijil akan disimpan dalam /etc/letsencrypt/live/example.com/, dan anda perlu menghalakan nginx atau Apache ke fullchain.pem dan privkey.pem seperti yang ditunjukkan dalam panduan asas, termasuk penggunaan deploy hook.

Jika pemalam pembekal anda tiada dalam apt

Arkib 24.04 hanya memaketkan pemalam untuk sebilangan kecil pembekal, antaranya Cloudflare, Route 53, DigitalOcean dan antara muka generik RFC 2136. Jalankan apt search certbot-dns untuk melihat senarai tersebut. Jika pembekal anda tiada, ini adalah satu-satunya keadaan di mana nasihat kami untuk mengutamakan apt perlu diketepikan: pasang Certbot dan pemalam tersebut melalui snap, dan buang Certbot versi apt terlebih dahulu supaya dua pemasa pembaharuan tidak bertembung pada /etc/letsencrypt:

sudo apt remove certbot python3-certbot-dns-cloudflare
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot
sudo snap set certbot trust-plugin-with-root=ok
sudo snap install certbot-dns-yourprovider

Pemalam snap hanya bersambung dengan Certbot snap; ia tidak boleh memanjangkan fungsi Certbot apt, itulah sebabnya kedua-dua pemasangan ini tidak boleh wujud bersama. Jika hos DNS anda tidak menawarkan sebarang API, pilihan realistik anda adalah memindahkan DNS domain tersebut kepada pembekal yang mempunyai API, atau menjalankan pelayan nama anda sendiri dan menghalakan pemalam rfc2136 kepadanya.

Pembaharuan: uji sekarang, bukan dalam 60 hari

Certbot merekodkan cara setiap sijil dikeluarkan dalam /etc/letsencrypt/renewal/example.com.conf, termasuk authenticator = dns-cloudflare dan laluan kelayakan, supaya pemasa dua kali sehari standard memperbaharuinya tanpa bantuan anda. Uji keseluruhan proses tersebut terhadap persekitaran staging:

sudo certbot renew --dry-run

Status pass bermakna kelayakan berfungsi dan pengesahan selesai sepenuhnya; pembaharuan sebenar dalam 60 hari akan mengikut laluan yang sama. Dua langkah susulan perlu dilakukan hari ini. Pertama, sijil yang diperbaharui pada cakera tidak mengubah apa-apa sehingga pelayan web memuatkannya semula, jadi sediakan deploy hook seperti yang diterangkan dalam panduan nginx dan Apache. Kedua, kendalikan fail kelayakan dengan berhati-hati: sesiapa yang boleh membacanya boleh menyunting zon DNS anda, yang mencukupi untuk mengubah hala e-mel anda atau melepasi cabaran DNS-01 milik mereka sendiri. Pastikan ia berada pada mod 600 di bawah /root, hadkan skop token kepada satu zon, dan tukar token tersebut jika anda mengesyaki sebarang kebocoran.

Apabila anda tidak memerlukan wildcard

Wildcard ialah alat yang tepat untuk banyak subdomain, atau untuk subdomain yang tidak dapat diramalkan. Ia merupakan pilihan lalai yang salah untuk perkara lain.

• Satu subdomain, atau beberapa subdomain yang diketahui: sijil SAN (subject alternative name) biasa adalah lebih ringkas. certbot --nginx -d example.com -d www.example.com -d app.example.com meliputi sehingga 100 nama melalui HTTP-01 biasa, dan tiada kelayakan API DNS yang perlu disimpan pada pelayan.
• Wildcard memadankan tepat satu label. *.example.com tidak meliputi example.com asas, itulah sebabnya arahan di atas meminta kedua-duanya, dan ia juga tidak meliputi a.b.example.com; itu memerlukan *.b.example.com.
• Satu kunci peribadi (private key) digunakan untuk setiap subdomain. Jika mesin yang menyimpannya diceroboh, setiap nama yang dilindungi oleh wildcard tersebut akan terjejas serentak.
• Jika Traefik menamatkan TLS (transport layer security) untuk kontena anda, anda tidak memerlukan Certbot sama sekali: Traefik meminta sijil wildcard sendiri melalui DNS-01, menggunakan jenis token pembekal yang sama.

Situasi di mana wildcard benar-benar berguna: subdomain bagi setiap pelanggan atau setiap aplikasi yang dicipta lebih pantas daripada kadar anda mengeluarkan semula sijil, dan hos dalaman tanpa port 80 awam, seperti servis yang hanya boleh dicapai melalui VPN WireGuard. DNS-01 tidak pernah bersambung ke hos yang diperakui, jadi mesin yang benar-benar peribadi pun boleh memegang sijil yang dipercayai secara awam.

FAQ

Bolehkah Certbot mengeluarkan sijil wildcard dengan HTTP-01?

Tidak. HTTP-01 membuktikan kawalan ke atas satu nama hos, kerana pelayan pengesahan mengambil fail token daripada nama yang tepat itu. Sijil wildcard meliputi setiap nama di bawah domain tersebut, jadi Let's Encrypt memerlukan cabaran DNS-01 untuknya, dan pengesah --nginx, --apache, --webroot serta --standalone semuanya berasaskan HTTP. Satu-satunya laluan ialah rekod TXT pada _acme-challenge.example.com, yang diletakkan secara manual atau oleh pemalam DNS.

Adakah sijil wildcard meliputi domain akar?

Tidak. Wildcard memadankan tepat satu label, jadi *.example.com meliputi www.example.com tetapi bukan example.com yang kosong, dan bukan a.b.example.com. Minta kedua-dua nama pada satu sijil dengan -d example.com -d '*.example.com'. Itu mencipta dua cabaran, dan kedua-dua rekod TXT berada pada nama _acme-challenge.example.com yang sama, jadi tambah rekod kedua tanpa memadamkan yang pertama.

Mengapa sijil wildcard saya tidak diperbaharui secara automatik?

Kerana ia dikeluarkan dengan --manual. Setiap pembaharuan memerlukan nilai TXT yang baharu, dan pemasa tanpa pengawasan tidak mempunyai cara untuk menampalnya, jadi pembaharuan terhenti dengan ralat An authentication script must be provided with --manual-auth-hook when using the manual plugin non-interactively. Keluarkan semula sijil dengan pemalam DNS seperti certbot-dns-cloudflare, atau sediakan skrip --manual-auth-hook dan --manual-cleanup-hook yang menyunting rekod melalui API pembekal anda.

Berapa lama masa yang diambil untuk rekod TXT _acme-challenge muncul?

Ia bergantung pada pembekal DNS anda: antara beberapa saat hingga beberapa minit. Pengesahan membaca pelayan autoritatif zon anda, jadi semak dengan dig +short TXT _acme-challenge.example.com @1.1.1.1 dan tunggu sehingga nilai yang dijangkakan muncul sebelum meneruskan proses manual. Dengan pemalam, tingkatkan masa tunggu terbina dalam melalui pilihan propagasi pemalam, contohnya --dns-cloudflare-propagation-seconds 60, jika pengesahan melaporkan bahawa rekod tidak ditemui.

Adakah sijil wildcard kurang selamat berbanding sijil biasa?

Kriptografinya adalah sama. Perbezaannya adalah dari segi operasi: satu kunci peribadi meliputi setiap subdomain, jadi jika berlaku pencerobohan, kesannya lebih meluas, dan kelayakan API DNS yang diperlukan oleh automasi itu sendiri adalah rahsia sensitif yang disimpan pada pelayan. Jika anda hanya menjalankan beberapa subdomain yang diketahui, sijil SAN mengelakkan kedua-dua kebimbangan tersebut, yang merupakan situasi tepat di mana panduan ini mengesyorkan agar tidak menggunakan wildcard.