Belajar Caddy - Custom Certificates & Internal CA

#Pendahuluan

Tidak semua sertifikat berasal dari CA publik. Di dalam jaringan perusahaan atau homelab, kalian sering butuh internal CA — otoritas sertifikat milik sendiri yang diterima oleh perangkat internal. Episode 10 membahas seluruh spektrum sertifikat kustom: manual, private CA, mTLS, otomasi dengan Step CA, hingga on-demand TLS.

Kalian akan belajar memasang sertifikat yang sudah ada, membangun kepercayaan untuk CA internal, mengaktifkan mutual TLS (mTLS) di mana klien juga harus menunjukkan sertifikat, menghubungkan Caddy ke internal ACME server, dan menggunakan on-demand TLS untuk SaaS multi-tenant.

Ini episode yang memberi kalian kendali penuh atas infrastruktur PKI — keterampilan yang langka dan berharga di dunia DevOps.

#Sertifikat Manual dan Chain PEM

#Format PEM dan Certificate Chain

Sertifikat di Caddy memakai format PEM — teks yang dibungkus -----BEGIN CERTIFICATE-----. Yang harus disiapkan:

• Leaf certificate: sertifikat untuk domain itu sendiri.
• Private key: pasangan kunci, wajib dirahasiakan.
• Intermediate certificate: pengikat leaf ke root CA.

Saat CA memberikan chain, gabungkan leaf dan intermediate dalam satu file, leaf di atas:

-----BEGIN CERTIFICATE-----
<leaf certificate>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<intermediate certificate>
-----END CERTIFICATE-----

Kemudian pasang di Caddyfile:

example.com {
    tls /etc/ssl/fullchain.pem /etc/ssl/privkey.pem
    root * /var/www
    file_server
}

tls fullchain.pem privkey.pem memakai chain file dan kunci yang sudah disiapkan. Urutan file yang salah membuat browser menolak sertifikat.

#Internal dan Private CA

#Self-Signed dan Kepercayaan Klien

Untuk CA internal, buat root CA sendiri lalu tanda tangani sertifikat domain. Cara tercepat adalah tls internal yang membuat Caddy menjadi CA:

internal.example.local {
    tls internal
    root * /var/www
    file_server
}

Agar klien mempercayai CA internal, import CA root Caddy ke trust store perangkat. Pada sistem Linux:

sudo cp /var/lib/caddy/.local/share/caddy/pki/authorities/local/root.crt /usr/local/share/ca-certificates/caddy-local.crt
sudo update-ca-certificates

Perintah sudo update-ca-certificates memperbarui daftar CA yang dipercaya sistem. Setelah ini, browser internal tidak lagi menampilkan peringatan.

#Enterprise PKI

Organisasi besar biasanya punya PKI sendiri (Microsoft AD CS, EJBCA, dan lainnya). Caddy bisa memakai sertifikat yang diterbitkan PKI tersebut lewat mekanisme manual. Yang penting: pastikan chain lengkap dan klien internal mempercayai root CA organisasi.

#Client Certificates (mTLS)

#Mengaktifkan Autentikasi Klien

mTLS meminta klien membuktikan identitas dengan sertifikat:

api.example.com {
    tls {
        client_auth {
            mode require_and_verify
            trusted_ca_certs /etc/ssl/client-ca.pem
        }
    }
    reverse_proxy localhost:8080
}

mode require_and_verify mewajibkan klien membawa sertifikat yang ditandatangani CA client-ca.pem. Request tanpa sertifikat valid langsung ditolak sebelum menyentuh aplikasi.

#Use Case mTLS

• API internal: hanya aplikasi dengan sertifikat yang boleh akses.
• Device authentication: perangkat IoT dengan identitas sertifikat.
• Microservices: komunikasi service-to-service yang terverifikasi.

mTLS adalah alternatif autentikasi yang jauh lebih kuat daripada API key karena berbasis kriptografi.

#Otomasi Sertifikat Internal

#Step CA dan Internal ACME Server

tls internal menghasilkan sertifikat yang sulit diperpanjang lintas instance. Solusi produksi: jalankan Step CA (Smallstep) sebagai internal ACME server, lalu arahkan Caddy ke sana:

{
    acme_ca https://ca.internal.example.com/acme/acme/directory
}
 
internal.example.local {
    root * /var/www
    file_server
}

Caddy memperlakukan Step CA seperti Let's Encrypt: issuance, renewal otomatis, dan storage sertifikat — semua berjalan sama, tapi dengan CA internal yang dipercaya organisasi. Ini memberi renewal otomatis untuk sertifikat internal tanpa sertifikat publik.

#On-Demand TLS

#Sertifikat Saat Diminta Pertama

On-demand TLS menerbitkan sertifikat hanya ketika request pertama datang untuk domain itu:

{
    on_demand_tls {
        ask https://auth.example.com/allow
    }
}
 
*.saas.example.com {
    tls {
        on_demand
    }
    reverse_proxy localhost:8080
}

on_demand memicu issuance saat request pertama untuk domain baru tiba. Endpoint ask menvalidasi apakah domain diizinkan — mencegah penyalahgunaan oleh pihak luar.

#Pertimbangan On-Demand TLS

• Rate limit: issuance per domain dibatasi CA; jangan lalai memvalidasi.
• Latency: request pertama lebih lambat karena menunggu issuance.
• Storage: sertifikat banyak domain mengisi storage dengan cepat.

On-demand TLS cocok untuk SaaS multi-tenant yang melayani domain kustom pengguna secara dinamis. Tanpa ask, siapa pun bisa membuat Caddy kalian meminta sertifikat untuk domain mereka — jadi selalu aktifkan validasi.

#Penutup

Episode 10 memberi kalian kendali penuh atas PKI: pemasangan sertifikat manual dengan chain PEM, pembentukan internal CA lewat tls internal dan trust store, pengaktifan mTLS dengan client_auth, otomasi sertifikat internal dengan Step CA sebagai ACME server, dan on-demand TLS untuk multi-tenant.

Inti yang harus dibawa pulang:

• PEM chain digabung dalam satu file, leaf di atas.
• tls internal menjadikan Caddy CA internal untuk development.
• Import root CA internal ke trust store agar klien percaya.
• client_auth dengan mode require_and_verify mengaktifkan mTLS.
• Step CA bisa menjadi ACME server internal untuk renewal otomatis.
• On-demand TLS wajib dilengkapi endpoint ask untuk validasi.

Di episode 11 selanjutnya kita masuk ke matchers & request filtering — konsep matcher, semua matcher standar seperti path, method, header, host, dan remote_ip, sintaks inline dan named, path matching dengan prefix dan wildcard, serta pola lanjutan dengan kombinasi matcher dan ekspresi CEL.