SSL Let’s Encrypt Windows Server 2008 R2 dan 2012 Cloudflare

Sertifikat Let’s Encrypt pada Windows Server versi lama dengan win-acme dan validasi DNS Cloudflare.

Cara memasang dan memperpanjang sertifikat Let’s Encrypt secara otomatis pada Windows Server versi lama dengan win-acme, validasi DNS Cloudflare, dan Apache XAMPP.

Sebelum Membaca.

Panduan ini ditujukan bagi pembaca yang sudah memahami cara kerja DNS challenge (DNS-01) dan sudah menyiapkan domain di Cloudflare beserta API token untuk zone yang bersangkutan. Pembuatan API token dan pengaturan zone tidak dibahas lagi di sini. Jika belum memilikinya, siapkan terlebih dahulu dengan merujuk pada dokumentasi resmi Cloudflare dan win-acme.

Seluruh contoh memakai nama domain fiktif app.contoh.id. Ganti dengan domain Anda sendiri.

Mengapa Windows Server Versi Lama?

Windows Server 2008 R2 dan 2012 sudah melewati masa dukungan Microsoft, tetapi di lapangan keduanya masih banyak dipakai. Penyebabnya sering bukan kelalaian pengelola server. Banyak aplikasi, terutama aplikasi untuk instansi pemerintah dan layanan kesehatan, dibangun dan dijalankan di atas versi sistem operasi tertentu. Mengganti sistem operasi pun bukan keputusan yang dapat diambil sendiri oleh pengelola server.

Karena itu, panduan ini sengaja membahas Windows Server versi lama. Windows Server versi modern tidak dibahas karena prosesnya lurus dan mudah: TLS 1.2 serta akar sertifikat Let’s Encrypt sudah tersedia sejak awal, sehingga hambatan yang dibahas di bawah ini tidak akan ditemui di sana.

Mengapa Tidak Memakai Linux Saja?

Pertanyaan ini hampir pasti muncul. Jawaban jujurnya: di Linux, Certbot dengan plugin DNS Cloudflare memang jauh lebih mudah, dan hal itu sudah terbukti dalam praktik. Namun, aplikasi yang dikelola berjalan di Windows Server dan tidak dapat dipindahkan begitu saja. Selain itu, ini adalah tantangan tersendiri: membuktikan bahwa Windows Server versi lama pun dapat mengurus sertifikatnya sendiri secara otomatis, tanpa membuka port masuk.

Jika Anda punya pilihan, Linux tetap lebih mudah. Panduan ini ditulis untuk pembaca yang tidak punya pilihan itu.

Latar Belakang: Sertifikat yang Dicoret (SSL Coret).

Awalnya sertifikat dibuat secara manual di server Linux lain dengan Certbot dan metode DNS, lalu berkasnya disalin ke server Windows melalui FTP. Cara ini berjalan, tetapi rapuh. Perpanjangan bergantung pada ingatan manusia setiap 60 sampai 90 hari. Ketika terlewat, peramban menampilkan HTTPS dengan tanda dicoret, dan pengguna aplikasi pun menegur.

Ada pula masalah keamanan. FTP biasa mengirim data tanpa enkripsi, termasuk kunci privat. Dengan win-acme, kunci privat dibuat di server itu sendiri dan tidak perlu dipindahkan ke mana pun.

Mengapa DNS-01 dengan Plugin Cloudflare?

Lingkungan yang menjadi dasar panduan ini memiliki tiga ciri. Akses publik melalui Cloudflare Zero Trust Tunnel (cloudflared). Akses lokal melalui static DNS di router MikroTik yang mengarahkan nama domain ke alamat IP privat server. Tidak ada port masuk yang dibuka di firewall.

Dengan ciri tersebut, pilihan metode validasi menjadi sempit:

• HTTP-01 (yang dipakai mode webroot) mengharuskan server Let’s Encrypt menghubungi server melalui port 80 dari internet. Ini bertentangan dengan prinsip tanpa port masuk.
• TLS-ALPN-01 membutuhkan port 443 yang dapat dijangkau dari internet, sehingga masalahnya sama.
• DNS-01 hanya meminta client membuat catatan TXT di DNS. Validasi terjadi antara Let’s Encrypt dan Cloudflare, sehingga server tidak perlu dapat dijangkau dari internet, termasuk ketika nama domain di jaringan lokal mengarah ke alamat IP privat.

Plugin Cloudflare membuat catatan TXT itu secara otomatis, termasuk saat perpanjangan. Tanpa plugin, catatan harus dibuat manual setiap kali, dan perpanjangan otomatis tidak mungkin dilakukan.

Secara teori, HTTP-01 juga dapat melewati tunnel. Namun, kebijakan akses Zero Trust atau pengalihan otomatis ke HTTPS dapat mengganggu permintaan verifikasi. Bagian ini belum diuji, sehingga cukup diperlakukan sebagai catatan.

Ringkasan Kompatibilitas.

Sistem Operasi	Versi win-acme yang Dipakai	Hasil Pengujian
Windows Server 2012	2.2.9.1701 (pluggable, x64) dengan plugin Cloudflare versi yang sama	Berhasil setelah TLS 1.2 sisi client diaktifkan
Windows Server 2008 R2 SP1	2.1.20.1185 (pluggable, x64) dengan plugin Cloudflare versi yang sama	Berhasil setelah pembaruan KB3140245 dan pengaturan TLS diterapkan
Windows Server 2008 (non-R2)	Tidak diuji	Kemungkinan besar tidak dapat dipakai (dugaan, belum diuji)

Beberapa aturan yang berlaku di semua versi:

• Pilih build pluggable. Build trimmed tidak dapat memuat plugin tambahan.
• Plugin Cloudflare diunduh terpisah dari berkas utama dan harus berasal dari rilis dengan nomor versi yang sama persis.
• Versi win-acme terbaru tidak otomatis berjalan di sistem operasi yang sangat tua. Untuk Windows Server 2008 R2, rilis yang dipakai adalah 2.1.20.

Langkah 1: Menyiapkan Berkas.

Unduh dari halaman rilis win-acme di GitHub. Jika koneksi HTTPS di server belum berfungsi, unduh di komputer lain lalu salin dengan flashdisk.

• Berkas win-acme build pluggable x64 sesuai tabel kompatibilitas.
• Berkas plugin Cloudflare dengan nomor versi yang sama.

Unblock kedua berkas zip sebelum diekstrak: klik kanan, pilih Properties, lalu centang Unblock. Ekstrak win-acme ke folder, misalnya C:\acme. Ekstrak plugin ke folder yang sama sehingga berkas .dll plugin berada di sebelah wacs.exe.

Jalankan Command Prompt sebagai Administrator, lalu:

cd C:\acme
wacs.exe --verbose

Periksa tiga hal pada log awal: versi program, baris yang menyatakan plugin Cloudflare berhasil dimuat, dan pesan Connection OK!. Jika muncul Connection failed, lanjutkan ke langkah berikutnya sesuai sistem operasi Anda.

Langkah 2: Mengatasi Koneksi TLS pada Windows Server 2012.

Gejala. Invoke-WebRequest dan wacs.exe gagal dengan pesan The underlying connection was closed: An unexpected error occurred on a receive, bahkan ke situs seperti Google. Padahal koneksi ke port 443 tembus, yang dapat dipastikan dengan Test-NetConnection www.google.com -Port 443.

Penyebab. TLS 1.2 untuk sisi client dimatikan di Schannel. Periksa dengan:

reg query "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client"

Jika hasilnya Enabled 0x0 dan DisabledByDefault 0x1, itulah penyebabnya.

Perbaikan:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v Enabled /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v DisabledByDefault /t REG_DWORD /d 0 /f
reg add HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /v SchUseStrongCrypto /t REG_DWORD /d 1 /f
reg add HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /f

Secara resmi, perubahan Schannel membutuhkan restart. Pada pengujian, pengaturan ini langsung berlaku tanpa restart untuk koneksi keluar. Hal ini penting bagi server produksi yang tidak boleh dimatikan. Setelah itu, uji ulang:

Invoke-WebRequest https://www.google.com -UseBasicParsing | Select StatusCode

Jika hasilnya 200, jalankan kembali wacs.exe --verbose dan pastikan Connection OK! muncul.

Langkah 3: Mengatasi Koneksi TLS pada Windows Server 2008 R2 SP1.

Windows Server 2008 R2 membutuhkan Service Pack 1. Periksa dengan:

systeminfo | findstr /B /C:"OS Name" /C:"OS Version"

Versi yang diharapkan adalah 6.1.7601 Service Pack 1.

Gejala. Uji koneksi dengan certutil:

certutil -urlcache -f https://acme-v02.api.letsencrypt.org/directory C:\test-acme.txt

Perintah ini gagal dengan kode 0x80072f8f ke alamat Let’s Encrypt, padahal ke situs lain seperti Google berhasil. Di Event Viewer (log System), sumber Schannel mencatat Event ID 36887 dengan pesan fatal alert was received: 70. Alert 70 berarti protocol_version: server Let’s Encrypt menolak karena versi TLS yang ditawarkan terlalu tua. Let’s Encrypt hanya menerima TLS 1.2 ke atas.

Log tersebut juga dapat dibaca lewat Command Prompt:

wevtutil qe System /q:"*[System[Provider[@Name='Schannel']]]" /c:5 /rd:true /f:text

Langkah yang dilakukan, berurutan.

1. Mengaktifkan TLS 1.2 sisi client di Schannel dan mengatur protokol aman untuk komponen internet. Perintah Schannel sama seperti pada Windows Server 2012. Tambahkan nilai berikut, yang mengaktifkan TLS 1.0, 1.1, dan 1.2 bagi komponen internet Windows:

reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings" /v SecureProtocols /t REG_DWORD /d 2688 /f
reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v SecureProtocols /t REG_DWORD /d 2688 /f

2. Memasang akar (root) sertifikat ISRG Root X1 (berkas .der dari situs Let’s Encrypt) ke penyimpanan Root. Pasang akar, bukan sertifikat perantara (intermediate):

certutil -addstore -f "Root" C:\isrgrootx1.der

3. Memeriksa pembaruan yang terpasang:

wmic qfe list brief | findstr "3140245"

Pada server yang diuji, KB3140245 belum terpasang. Pembaruan ini menyediakan dukungan TLS 1.1 dan 1.2 sebagai protokol aman bawaan di WinHTTP.

4. Memasang KB3140245. Unduh berkas .msu untuk Windows Server 2008 R2 x64 dari Microsoft Update Catalog di komputer lain, lalu salin ke server. Jika pemasang meminta pembaruan prasyarat, ikuti pesan yang muncul.

5. Menerapkan pengaturan WinHTTP:

reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp" /v DefaultSecureProtocols /t REG_DWORD /d 2048 /f
reg add "HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp" /v DefaultSecureProtocols /t REG_DWORD /d 2048 /f

6. Memulai ulang server, lalu mengulang uji certutil. Hasilnya completed successfully.

Catatan pengujian. Beberapa pengaturan diterapkan bersamaan, sehingga belum diketahui satu per satu mana yang benar-benar wajib. Satu hal yang terbukti: setelah pengaturan registry dan restart, uji certutil masih gagal dengan alert 70. Uji baru berhasil setelah KB3140245 terpasang. Pada langkah ini juga belum diuji apakah ISRG Root X1 wajib dipasang.

Setelah koneksi berfungsi, jalankan wacs.exe --verbose dan pastikan Connection OK! muncul.

Langkah 4: Menerbitkan Sertifikat.

Alur menu pada kedua versi win-acme hampir sama. Tampilan teks di versi 2.1.x sedikit berbeda dari versi 2.2.x, jadi pilihlah berdasarkan tulisannya, bukan nomornya.

1. Jalankan wacs.exe sebagai Administrator, lalu tekan M (create certificate with full options).
2. Source: pilih Manual input, lalu isi nama host, misalnya app.contoh.id.
3. Jika ditanya soal pemecahan sertifikat, pilih Single certificate.
4. Validation: pilih DNS-01, yaitu opsi Create verification records in Cloudflare DNS.
5. Tempel API token Cloudflare yang sudah disiapkan. Jika ditawari menyimpan ke vault, beri nama yang mudah dikenali.
6. Jenis kunci privat: pilih RSA. RSA paling kompatibel dengan berbagai versi Apache.
7. Store: pilih PEM encoded files. Isi folder tujuan, misalnya C:\xampp\apache\conf\ssl. Buat folder itu terlebih dahulu jika belum ada.
8. Kata sandi berkas kunci privat: pilih None. Apache tidak dapat membaca kunci berkata sandi saat dijalankan otomatis.
9. Pada pertanyaan penyimpanan tambahan, pilih No (additional) store steps. Pada tahap instalasi, pilih No (additional) installation steps.
10. Isi alamat email yang aktif dan setujui ketentuan layanan Let’s Encrypt.
11. Jika win-acme menawarkan pembuatan scheduled task untuk perpanjangan otomatis, terima tawaran itu.

Setelah selesai, folder tujuan berisi empat berkas:

app.contoh.id-crt.pem: sertifikat server saja.
app.contoh.id-chain-only.pem: sertifikat perantara saja.
app.contoh.id-chain.pem: gabungan keduanya.
app.contoh.id-key.pem: kunci privat.

Ini konsisten dengan ukuran berkas: ukuran chain.pem sama dengan jumlah ukuran crt.pem dan chain-only.pem.

Langkah 5: Memasang Sertifikat di Apache XAMPP.

Pakai chain.pem dan key.pem. Ubah dua baris di konfigurasi VirtualHost port 443:

SSLCertificateFile "C:/xampp/apache/conf/ssl/app.contoh.id-chain.pem"
SSLCertificateKeyFile "C:/xampp/apache/conf/ssl/app.contoh.id-key.pem"

Beberapa hal yang perlu diperhatikan:

• Salin konfigurasi lama sebagai cadangan sebelum mengubahnya.
• Beri tanda # pada baris SSLCertificateChainFile yang masih aktif. Berkas chain.pem sudah berisi sertifikat perantara.
• Jangan memasangkan kunci lama dengan sertifikat baru, atau sebaliknya. Pasangan yang tidak cocok membuat Apache gagal berjalan.

Uji sintaks sebelum memulai ulang:

C:\xampp\apache\bin\httpd.exe -t

Jika hasilnya Syntax OK, mulai ulang Apache melalui XAMPP Control Panel pada jam yang aman. Lalu buka alamat situs dan klik ikon gembok di peramban untuk memeriksa penerbit serta tanggal kedaluwarsa. Sertifikat Let’s Encrypt berlaku 90 hari.

Langkah 6: Perpanjangan Otomatis.

Win-acme membuat scheduled task bernama kurang lebih win-acme renew, yang berjalan setiap hari dan hanya memperbarui sertifikat yang sudah mendekati jatuh tempo.

Untuk mengujinya, buka taskschd.msc, cari task tersebut di Task Scheduler Library, klik kanan, lalu pilih Run. Segarkan tampilan dan lihat kolom Last Run Result. Nilai 0x0 berarti task berjalan tanpa kesalahan. Karena sertifikat belum mendekati jatuh tempo, tidak ada sertifikat baru yang diterbitkan, dan hal itu wajar.

Jangan menambahkan opsi --force saat menguji. Opsi itu menerbitkan sertifikat baru dan dihitung dalam batas penerbitan Let’s Encrypt.

Hal lain yang perlu dijaga:

• Task berjalan dengan akun yang kata sandinya dimasukkan saat pembuatan. Jika kata sandi akun diganti, task perlu diperbarui.
• Jangan memindahkan atau menghapus folder tempat wacs.exe berada.
• Apache tidak otomatis membaca berkas yang baru. Perlu dimulai ulang setelah perpanjangan. Pada lingkungan ini, penyelenggara server memulai ulang Apache secara manual. Pastikan satu kali mulai ulang terjadi setelah perpanjangan dan sebelum sertifikat lama habis.
• Nonaktifkan task atau skrip lama (misalnya Certbot atau penyalinan lewat FTP) agar tidak ada dua sumber sertifikat yang saling bertabrakan.

Sertifikat Beres, Rencana Migrasi Tetap Perlu.

Sertifikat yang valid hanya mengamankan jalur data antara peramban dan server. Windows Server 2008 R2 dan 2012 tidak lagi mendapat pembaruan keamanan reguler, sehingga celah pada sistem operasi, XAMPP, dan aplikasi tetap terbuka. HTTPS yang bergembok tidak membuat server lama menjadi aman.

Agar risikonya terkendali, beberapa langkah berikut layak dipertimbangkan:

• Buka hanya port yang benar-benar diperlukan, dan batasi sumber aksesnya jika memungkinkan.
• Jangan memakai server itu untuk menjelajah web, dan batasi akses RDP atau lewatkan melalui VPN.
• Letakkan layanan di balik tunnel atau reverse proxy, seperti yang dilakukan dalam panduan ini, agar server tidak berhadapan langsung dengan internet.
• Tetap pasang pembaruan yang masih tersedia untuk Apache, PHP, dan komponen lain.

Panduan ini menjawab satu masalah nyata: sertifikat yang tidak lagi dicoret dan diperpanjang tanpa campur tangan manusia. Langkah jangka panjangnya tetap sama, yaitu merencanakan migrasi ke sistem operasi yang masih mendapat dukungan.