Google menggunakan teknologi AI untuk menerjemahkan konten ke dalam bahasa pilihan Anda. Terjemahan AI mungkin mengandung kesalahan.

Penerapan referensi EJBCA Keyfactor

Ringkasan

Panduan ini menjelaskan integrasi Keyfactor EJBCA Enterprise (di-deploy sebagai appliance eksternal) sebagai Otoritas Sertifikat (CA) pihak ketiga untuk Google Distributed Cloud (GDC) yang terisolasi.

Keyfactor EJBCA Enterprise adalah platform Certificate Authority yang sangat skalabel, andal, dan sesuai dengan FIPS yang memungkinkan organisasi mengelola infrastruktur kunci publik (PKI) di seluruh lingkungan heterogen.

GDC dengan air gap mencakup layanan Certificate Authority bawaan untuk pengelolaan kunci dan sertifikat otomatis di dalam batas cloud yang dihosting. Namun, organisasi yang telah menstandardisasi infrastruktur PKI mereka di Keyfactor EJBCA untuk workload yang ada di luar GDC mungkin lebih memilih untuk memanfaatkan arsitektur CA dan kebijakan pengelolaan yang sama dan konsisten untuk workload yang berjalan dalam lingkungan GDC yang terisolasi.

Panduan ini menunjukkan cara mengonfigurasi jaringan GDC, DNS internal, dan cert-manager Kubernetes untuk mengotomatiskan pengelolaan siklus proses sertifikat (ACME) dan mendukung penerbitan terprogram bervolume tinggi menggunakan pola Otoritas Pendaftaran (RA).

Asumsi

Sebelum melanjutkan panduan ini, pastikan asumsi berikut terpenuhi:

Keyfactor EJBCA di-deploy sebagai appliance software atau appliance hardware, dan alamat IP yang stabil dikonfigurasi untuk layanan tersebut.
Root, subordinate, dan Certificate Authority (CA) pengelolaan telah dibuat di instance EJBCA.
Profil Entitas Akhir (EE) telah dikonfigurasi (misalnya, untuk sertifikat server TLS).
Sertifikat untuk pengguna CA administratif telah didownload.
Protokol yang diperlukan (seperti ACME) diaktifkan di instance EJBCA.
Algoritma penandatanganan RSA digunakan dalam panduan ini. Anda dapat mengubah algoritma penandatanganan berdasarkan persyaratan spesifik Anda atau apa yang dikonfigurasi di instance EJBCA Anda.

Arsitektur

Arsitektur ini mengikuti model Otoritas Sertifikat eksternal, di mana server EJBCA dan Modul Keamanan Hardware (HSM) pendukungnya dihosting secara eksternal di luar batas GDC fisik, tetapi dapat diakses melalui jaringan. Server EJBCA dapat di-deploy secara eksternal sebagai appliance hardware atau software. Integrasi inti yang dijelaskan dalam panduan ini hanya memerlukan server EJBCA eksternal dapat dijangkau menggunakan alamat IP yang stabil.

Diagram arsitektur Keyfactor EJBCA.

Komponen utama arsitektur ini meliputi:

EJBCA Enterprise Server: Di-deploy secara eksternal sebagai appliance hardware atau software Keyfactor, yang menyimpan CA (Root dan Subordinat) serta membuat semua materi kunci CA di dalam HSM bersertifikasi CC EAL4+.
Cluster Kubernetes Standar GDC: Lingkungan komputasi yang menjalankan beban kerja pelanggan, cert-manager, dan proxy integrasi.
DNS Internal GDC: Mengelola zona DNS pribadi lokal (menggunakan nama domain pribadi yang dikonfigurasi dalam variabel lingkungan) yang digunakan untuk menyelesaikan tantangan ACME DNS-01.
GDC Egress Gateway: Mengarahkan traffic keluar dari pod cluster ke alamat IP server EJBCA eksternal.
Harbor Private Registry: Menampung image container yang di-mirror (seperti penerbit cert-manager EJBCA) untuk deployment yang terisolasi.

Sebelum memulai

Pastikan lingkungan GDC Anda memenuhi persyaratan berikut sebelum memulai integrasi:

Pertama, buat project yang akan berfungsi sebagai penampung untuk semua resource yang dihasilkan di sepanjang panduan ini.

Konfigurasi variabel lingkungan yang akan dirujuk di seluruh panduan ini. Ubah nilai ini sesuai kebutuhan agar cocok dengan lingkungan spesifik Anda:

# GDC Environment Configuration
export GDC_ORG="your-org-name"
export GDC_ZONE="your-zone-name"
export GDC_PROJECT_ID="your-project-id"
export GDC_USER_NAME="your-gdc-user-email"
export GDC_CLUSTER_NAME="your-cluster-name"

# EJBCA Server Configuration
export EJBCA_DNS_ZONE="example.internal"
export EJBCA_HOSTNAME="ejbca.${EJBCA_DNS_ZONE}"
export EJBCA_LB_IP="XX.XX.XX.XX" # Stable IP of your EJBCA Server
export EJBCA_CA_NAME="GDC Subordinate CA"
export EJBCA_NAMESPACE="ejbca-ee"
export CERTIFICATE_PROFILE_NAME="GDC TLS SERVER PROFILE"
export END_ENTITY_PROFILE_NAME="GDC TLS SERVER EE PROFILE"

# Harbor Private Registry Configuration
export HARBOR_INSTANCE_URL="your-harbor-url.internal"
export HARBOR_PROJECT="your-harbor-project"
export HARBOR_ROBOT_ACCOUNT="robot$your-robot-name"
export HARBOR_ROBOT_SECRET="your-robot-secret"
export HARBOR_PULL_SECRET_NAME="harbor-secret"

Catatan Jaringan: Panduan ini mengasumsikan bahwa panduan dijalankan dari node bastion yang memiliki akses ke API GDC dengan air gap dan juga memiliki akses ke internet untuk mendownload manifes dan image container yang diperlukan. Jika Anda menjalankan ini dari komputer tanpa akses internet, Anda harus mendapatkan aset ini secara terpisah (misalnya, menggunakan docker save untuk mengekspor gambar dari komputer yang terhubung dan docker load untuk mengimpornya) dan menguploadnya dengan aman ke lingkungan Anda sebelum melanjutkan.

Mengonfigurasi alias kubectl

Di bagian ini, Anda akan membuat alias command line yang mudah digunakan untuk API global dan pengelolaan zonal GDC:

Buat alias untuk API pengelolaan zona (Ganti MANAGEMENT_API_KUBECONFIG dengan jalur ke kubeconfig untuk API pengelolaan):
```
alias km="kubectl --kubeconfig MANAGEMENT_API_KUBECONFIG"
```
Buat alias untuk API global (Ganti GLOBAL_API_KUBECONFIG dengan jalur ke kubeconfig untuk API global):
```
alias kg="kubectl --kubeconfig GLOBAL_API_KUBECONFIG"
```

Buat cluster standar GDC

Di bagian ini, Anda akan men-deploy cluster Kubernetes standar di dalam GDC dan mengonfigurasi peran administrator cluster standar GDC serta kredensial registry container Harbor lokal:

1. Identifikasi jenis image virtual machine yang tersedia dengan menjalankan:

```shell
gdcloud compute machine-types list
```

2. Pilih jenis mesin yang sesuai untuk node pekerja cluster Anda:

```shell
export MACHINE_TYPE="n3-standard-8-gdc"
```

3 Buat cluster standar dengan dua node pekerja menggunakan API pengelolaan zona:

```shell
km create -f - <<EOF
apiVersion: cluster.gdc.goog/v1
kind: Cluster
metadata:
  name: ${GDC_CLUSTER_NAME}
  namespace: ${GDC_PROJECT_ID}
spec:
  nodePools:
  - machineTypeName: ${MACHINE_TYPE}
    nodeCount: 2
    name: ${GDC_CLUSTER_NAME}-node-pool
EOF
```

This creates a simple GDC cluster. Cluster creation
can take up to 60 minutes to complete. To check the status, use the
following command:

```shell
km get clusters/${GDC_CLUSTER_NAME} \
  -n ${GDC_PROJECT_ID} \
  --watch
```

After the cluster is ready, the output should show a STATE of `Running`.

4 Setelah cluster siap, ambil kredensialnya:

```shell
KUBECONFIG=kubeconfig-${GDC_CLUSTER_NAME}.yaml gdcloud clusters \
  get-credentials ${GDC_CLUSTER_NAME} \
  --standard \
  --project ${GDC_PROJECT_ID} \
  --zone ${GDC_ZONE}
```

5 Tetapkan peran administrator cluster standar GDC kepada pengguna GDC Anda:

```shell
gdcloud projects add-iam-policy-binding ${GDC_PROJECT_ID} \
  --member="user:${GDC_USER_NAME}" \
  --role=cluster-admin

gdcloud projects add-iam-policy-binding ${GDC_PROJECT_ID} \
  --member="user:${GDC_USER_NAME}" \
  --role=standard-cluster-admin
```

6 Buat instance Harbor dan project Harbor di GDC untuk menghosting image container yang di-mirror:

```shell
gdcloud projects add-iam-policy-binding ${GDC_PROJECT_ID} \
  --member="user:${GDC_USER_NAME}" \
  --role=harbor-instance-admin
```

7 Buat akun robot Harbor dan catat nama pengguna serta kunci rahasianya.

8 Lakukan autentikasi dengan instance Harbor Anda:

```shell
docker --config=./docker-harbor login ${HARBOR_INSTANCE_URL} \
  -u ${HARBOR_ROBOT_ACCOUNT} \
  -p ${HARBOR_ROBOT_SECRET}
```

This saves the robot account credentials to
`./docker-harbor/config.json` for subsequent Secret creation.

Konfigurasi infrastruktur dan jaringan

Di bagian ini, Anda akan mengonfigurasi infrastruktur GDC dan setelan jaringan yang mendasarinya. Hal ini memastikan bahwa beban kerja Kubernetes Anda dapat menyelesaikan nama domain host EJBCA eksternal dan berhasil merutekan panggilan API keluar ke alamat IP-nya.

Penyiapan DNS Pribadi di GDC dengan air gap

Untuk membuat resolusi domain, Anda men-deploy set data dan zona DNS pribadi untuk memetakan server EJBCA eksternal ke nama domain lokal, sehingga layanan di dalam GDC dapat terhubung menggunakan nama host yang stabil, bukan alamat IP mentah:

Tetapkan peran Admin Project Managed DNS kepada pengguna Anda:

gdcloud projects add-iam-policy-binding ${GDC_PROJECT_ID} \
  --member=user:${GDC_USER_NAME} \
  --role=managed-dns-project-admin

Deploy resource ManagedDNSZone global:

kubectl --kubeconfig GLOBAL_API_KUBECONFIG apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ManagedDNSZone
metadata:
  name: private-example-internal
  namespace: ${GDC_PROJECT_ID}
spec:
  dnsName: ${EJBCA_DNS_ZONE}
  visibility: PRIVATE
EOF

Deploy ResourceRecordSet yang mengarah ke alamat IP appliance EJBCA Anda:

kubectl --kubeconfig GLOBAL_API_KUBECONFIG apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ResourceRecordSet
metadata:
  name: ${EJBCA_HOSTNAME}
  namespace: ${GDC_PROJECT_ID}
spec:
  name: ${EJBCA_HOSTNAME}
  ttlSeconds: 600
  type: A
  rrData:
  - ${EJBCA_LB_IP}
  dnsZone: private-example-internal
EOF

Penyiapan gateway NAT keluar

Selanjutnya, Anda mengonfigurasi jaringan keluar GDC dengan menyiapkan subnet kustom dan gateway NAT untuk mengizinkan workload Kubernetes (seperti cert-manager dan klien Otoritas Pendaftaran) merutekan traffic keluar ke server EJBCA secara aman:

Menetapkan peran developer jaringan tingkat project dan organisasi:

gdcloud projects add-iam-policy-binding ${GDC_PROJECT_ID} \
  --member=user:${GDC_USER_NAME} \
  --role=cloud-nat-developer

gdcloud projects add-iam-policy-binding ${GDC_PROJECT_ID} \
  --member=user:${GDC_USER_NAME} \
  --role=subnet-project-admin

gdcloud organizations add-iam-policy-binding ${GDC_ORG} \
  --member="user:${GDC_USER_NAME}" \
  --role=subnet-org-admin

Buat subnet keluar:

kubectl --kubeconfig MANAGEMENT_API_KUBECONFIG apply -f - <<EOF
apiVersion: ipam.gdc.goog/v1
kind: Subnet
metadata:
  name: ejbca-cluster-egress
  namespace: ${GDC_PROJECT_ID}
spec:
  ipv4Request:
    prefixLength: 32
  parentReference:
    name: data-network-segment-${GDC_ZONE}-group
    namespace: platform
    type: SubnetGroup
  type: Leaf
EOF

Buat CloudNATGateway yang cocok dengan pemilih penerbit cert-manager:

kubectl --kubeconfig MANAGEMENT_API_KUBECONFIG apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: CloudNATGateway
metadata:
  name: ejbca-egress-gateway
  namespace: ${GDC_PROJECT_ID}
spec:
  subnetRefs:
  - ejbca-cluster-egress
  workloadSelector:
    labelSelector:
      clusters:
        matchLabels:
          kubernetes.io/metadata.name: ${GDC_CLUSTER_NAME}
      workloads:
        matchLabels:
          app.kubernetes.io/name: ejbca-cert-manager-issuer
EOF

Integrasi cert-manager Kubernetes

Di bagian ini, Anda akan mengintegrasikan penerbit cert-manager EJBCA kustom dengan layanan cert-manager GDC. Dengan begitu, Anda dapat membuat penyediaan, perpanjangan, dan pengelolaan siklus proses sertifikat otomatis untuk layanan yang di-container.

Diagram integrasi cert-manager EJBCA.

Mengonfigurasi EJBCA untuk penerbit

Untuk mengintegrasikan penerbit, Anda mengonfigurasi profil yang diperlukan, mendaftarkan kredensial klien administrasi, dan menyiapkan pengikatan peran di dalam server EJBCA. Langkah ini akan membuat saluran administratif yang aman yang memungkinkan cert-manager melakukan autentikasi dengan dan meminta sertifikat dari EJBCA.

Membuat profil sertifikat admin

Anda memulai dengan membuat profil sertifikat di dalam EJBCA untuk menentukan properti teknis dan batasan kriptografi (seperti algoritma dan periode validitas) sertifikat administratif:

Buka UI Admin EJBCA, buka CA Functions > Certificate Profiles.
Clone profil ENDUSER dan beri nama GDC ADMIN PROFILE.
Edit GDC ADMIN PROFILE dan konfigurasi setelan berikut:
- Algoritma Kunci yang Tersedia: RSA
- Panjang Bit yang Tersedia: 2048, 3072, 4096
- Signature Algorithm: SHA512WithRSA
- Validitas: 200d
- Nama Alternatif Penerbit: Jelas Penggunaan
- Lokasi Distribusi CRL: Periksa Gunakan
- Gunakan Lokasi Distribusi CRL yang ditentukan CA: Centang Gunakan
- Akses Informasi Otoritas: Periksa Gunakan
- Gunakan pencari OCSP yang ditentukan CA: Centang Gunakan
- Menggunakan penerbit CA yang ditentukan CA: Centang Gunakan
- CA yang tersedia: Pilih GDC Subordinate CA
Klik Simpan.

Membuat profil entity akhir administrator

Selanjutnya, Anda akan membuat profil entity akhir di EJBCA untuk menentukan kolom default dan penetapan CA, yang menyederhanakan proses pendaftaran dan penerbitan sertifikat administratif:

Buka RA Functions > End Entity Profiles.
Di bagian Tambahkan Profil Entitas Akhir, masukkan GDC ADMIN EE PROFILE, lalu klik Tambahkan Profil.
Edit profil dan konfigurasi setelan berikut:
- Profil Sertifikat Default: GDC ADMIN PROFILE
- Profil Sertifikat yang Tersedia: GDC ADMIN PROFILE
- CA Default: GDC Subordinate CA
- CA yang Tersedia: GDC Subordinate CA
Klik Simpan.

Mendaftarkan sertifikat administrator

Setelah profil dibuat, daftarkan identitas administratif menggunakan antarmuka EJBCA Registration Authority (RA) dan ekstrak kunci pribadi, sertifikat publik, dan rantai kepercayaan untuk membuat file kredensial fisik yang diperlukan untuk mengautentikasi cert-manager:

Buka tab RA Web.
Klik Buat Permintaan Baru dan konfigurasi:
- Certificate Type: GDC ADMIN EE PROFILE
- Pembuatan pasangan kunci: Oleh CA
- Algoritma kunci: RSA 4096 bit
- Nama Umum (CN): cert-manager
- Username: cert-manager
- Kode pendaftaran: abcd
Klik Download PEM dan simpan sebagai cert-manager.pem.

Pisahkan file PEM menjadi tiga file:

client.key (kunci rahasia):

openssl pkey -in cert-manager.pem -out client.key

client.crt (sertifikat publik):

openssl x509 -in cert-manager.pem -out client.crt

ca.crt (rantai kepercayaan dengan sertifikat CA bawahan dan root):

awk '/BEGIN CERTIFICATE/{i++} i>1' cert-manager.pem > ca.crt

Mengonfigurasi peran dan aturan akses

Terakhir, Anda membuat peran administratif di EJBCA dan mengikatnya ke nomor seri sertifikat cert-manager untuk memastikan penerbit hanya memiliki kumpulan izin minimal yang diperlukan untuk menyetujui dan meminta sertifikat:

Di UI Admin EJBCA, buka RA Functions > Search End Entities.
Cari entitas akhir cert-manager dan catat Nomor Seri Sertifikat-nya.
Buka System Functions > Roles and Access Rules, lalu klik Add.
Beri nama peran cert-manager dan tambahkan anggota baru menggunakan nomor seri yang Anda catat.
Klik Edit Aturan Akses dan konfigurasi hak istimewa berikut:
- Template Peran: Administrator RA
- CA Resmi: GDC Subordinate CA
- Aturan Entitas Akhir: Menyetujui, Membuat, dan Mengedit Entitas Akhir
- Profil Entitas Akhir: GDC TLS SERVER EE PROFILE
- Aturan Lainnya: hapus Lihat Log Audit
Klik Simpan.

Menyiapkan cluster GDC

Untuk menyiapkan lingkungan GDC, Anda melakukan autentikasi dengan cluster Kubernetes standar dan menyimpan kredensial administratif EJBCA yang diekstrak di dalam Secret Kubernetes, sehingga dapat diakses dengan aman oleh pod penerbit cert-manager:

Ambil kredensial cluster standar:

gdcloud clusters get-credentials "${GDC_CLUSTER_NAME}" \
  --standard \
  --project "${GDC_PROJECT_ID}" \
  --zone "${GDC_ZONE}"

Buat namespace target untuk penerbit kustom:
```
kubectl create ns ejbca-issuer-system
```

Deploy rahasia autentikasi TLS:

kubectl create secret tls ejbca-secret \
  -n ejbca-issuer-system \
  --cert=client.crt \
  --key=client.key

Deploy secret rantai kepercayaan EJBCA:

kubectl create secret generic ejbca-ca-secret \
  -n ejbca-issuer-system \
  --from-file=ca.crt

Menginstal penerbit EJBCA

Untuk mengonfigurasi deployment, Anda mencerminkan image container penerbit cert-manager EJBCA ke registry Harbor pribadi dan men-deploy diagram Helm. Tindakan ini meng-instansiasi pengontrol kustom yang diperlukan untuk menerjemahkan permintaan sertifikat Kubernetes menjadi panggilan API EJBCA:

Buat secret penarikan image Harbor di namespace penerbit:

# Authenticate with the private Harbor registry
docker --config=./docker-harbor login ${HARBOR_INSTANCE_URL} \
  -u ${HARBOR_ROBOT_ACCOUNT} \
  -p ${HARBOR_ROBOT_SECRET}

kubectl create secret docker-registry ${HARBOR_PULL_SECRET_NAME} \
  --from-file=.dockerconfigjson=./docker-harbor/config.json \
  -n ejbca-issuer-system

Salin image penerbit cert-manager EJBCA resmi ke Harbor:

docker pull keyfactor/ejbca-cert-manager-issuer:latest --platform linux/amd64

docker tag keyfactor/ejbca-cert-manager-issuer:latest \
  ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/ejbca-cert-manager-issuer:latest

docker --config=./docker-harbor push \
  ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/ejbca-cert-manager-issuer:latest

Tambahkan repositori Helm dan download diagram:

helm repo add ejbca-issuer https://keyfactor.github.io/ejbca-cert-manager-issuer
helm repo update
helm pull ejbca-issuer/ejbca-cert-manager-issuer --untar

Deploy diagram Helm menggunakan repositori image yang di-mirror:

helm install ejbca-cert-manager-issuer ./ejbca-cert-manager-issuer \
  --namespace ejbca-issuer-system \
  --set image.repository=${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/ejbca-cert-manager-issuer \
  --set "imagePullSecrets[0].name=${HARBOR_PULL_SECRET_NAME}" \
  --set image.tag=latest

Buat resource penerbit

Selanjutnya, Anda akan menetapkan izin RBAC GDC dan men-deploy resource ClusterIssuer global, yang mendaftarkan server EJBCA sebagai sumber penandatanganan tepercaya dalam framework cert-manager Kubernetes:

Konfigurasi izin RBAC untuk mengizinkan pengontrol cert-manager GDC menggunakan penerbit EJBCA kustom:

kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cert-manager-controller-approve:issuers-ejbca-issuer-keyfactor-com
rules:
- verbs:
  - approve
  apiGroups:
  - cert-manager.io
  resources:
  - signers
  resourceNames:
  - issuers.ejbca-issuer.keyfactor.com/*
  - clusterissuers.ejbca-issuer.keyfactor.com/*
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cert-manager-controller-approve:issuers-ejbca-issuer-keyfactor-com
subjects:
- kind: ServiceAccount
  name: cert-manager
  namespace: cert-manager
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cert-manager-controller-approve:issuers-ejbca-issuer-keyfactor-com
EOF

Deploy resource ClusterIssuer global:

kubectl apply -f - <<EOF
apiVersion: ejbca-issuer.keyfactor.com/v1alpha1
kind: ClusterIssuer
metadata:
  name: clusterissuer-ejbca
spec:
  hostname: "${EJBCA_HOSTNAME}"
  ejbcaSecretName: "ejbca-secret"
  caBundleSecretName: "ejbca-ca-secret"
  certificateAuthorityName: "${EJBCA_CA_NAME}"
  certificateProfileName: "${CERTIFICATE_PROFILE_NAME}"
  endEntityProfileName: "${END_ENTITY_PROFILE_NAME}"
  endEntityName: ""
EOF

Verifikasi status penerbit:

kubectl get clusterissuer.ejbca-issuer.keyfactor.com/clusterissuer-ejbca \
  -o "custom-columns=NAME:.metadata.name,STATUS:.status.conditions[0].message"

Output akan menampilkan:

NAME                  STATUS
clusterissuer-ejbca   Success

Meminta sertifikat

Untuk memverifikasi integrasi, Anda men-deploy resource Sertifikat Kubernetes standar untuk menguji alur cert-manager end-to-end dan mengonfirmasi bahwa EJBCA berhasil menandatangani dan menyediakan sertifikat yang diminta:

Buat resource Certificate pengujian untuk memverifikasi keberhasilan integrasi:

kubectl apply -f - <<EOF
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: ejbca-test-certificate
  namespace: ${EJBCA_NAMESPACE}
spec:
  commonName: example.com
  secretName: ejbca-certificate
  issuerRef:
    name: clusterissuer-ejbca
    group: ejbca-issuer.keyfactor.com
    kind: ClusterIssuer
EOF

Pastikan sertifikat telah dibuat dan siap:

kubectl get certificates.cert-manager.io -n ${EJBCA_NAMESPACE}

Output akan menampilkan:

NAME                     READY   SECRET              AGE
ejbca-test-certificate   True    ejbca-certificate   12s

ACME otomatis dengan tantangan DNS-01

Di bagian ini, Anda akan mengonfigurasi layanan ACME EJBCA dan memanfaatkan resource DNS internal GDC untuk mengotomatiskan penerbitan sertifikat yang divalidasi domain. Hal ini memungkinkan klien cert-manager atau Certbot standar untuk meminta sertifikat menggunakan protokol ACME otomatis standar.

Mengonfigurasi EJBCA untuk ACME

Untuk menyiapkan server, Anda mengaktifkan layanan ACME di dalam EJBCA dan mengonfigurasi alias ACME dengan resolver DNS khusus. Tindakan ini menyiapkan server EJBCA untuk memproses dan memvalidasi respons tantangan DNS-01 di dalam GDC:

Di UI Admin EJBCA, buka System Configuration > ACME Configuration.
Klik Tambahkan dan konfigurasi hal berikut:
- Nama: default
- End entity profile: GDC TLS SERVER EE PROFILE
- Penerbitan Sertifikat Karakter Pengganti Diizinkan: Periksa
- Jenis tantangan DNS validasi MPIC Respons Tantangan: Pilih dns-01
- DNS resolver: Masukkan IP DNS global Anda.
- Validasi DNSSEC: jelas (karena ini adalah lingkungan pribadi lokal)
Klik Simpan.

Buat variabel lingkungan ACME

Di bagian ini, Anda akan membuat variabel lingkungan berikut untuk mengonfigurasi klien Certbot. Ubah nilai ini sesuai kebutuhan:

# ACME Alias created in the EJBCA configuration
export ACME_ALIAS="default"

# Arbitrary email address used for ACME registration
export ACME_EMAIL="your-email@example.com"

Mendaftarkan klien Certbot

Selanjutnya, Anda menginstal klien Certbot standar dan mendaftarkannya dengan endpoint ACME pribadi EJBCA. Tindakan ini akan membuat akun klien tepercaya yang diperlukan untuk melakukan operasi sertifikat otomatis:

Instal certbot di workstation Anda. Misalnya, untuk macOS:
```
brew install certbot
```

Buat folder lokal untuk konfigurasi dan log:

mkdir -p ./certbot/config ./certbot/work ./certbot/logs

Daftarkan klien dengan endpoint direktori ACME EJBCA:

certbot register \
  --config-dir ./certbot/config \
  --work-dir ./certbot/work \
  --logs-dir ./certbot/logs \
  --server https://${EJBCA_HOSTNAME}/ejbca/acme/${ACME_ALIAS}/directory \
  --email ${ACME_EMAIL} \
  --agree-tos \
  --no-eff-email

Menerbitkan sertifikat menggunakan tantangan DNS

Terakhir, Anda menjalankan permintaan Certbot manual dan men-deploy resource TXT DNS GDC sementara untuk menyelesaikan verifikasi DNS-01. Hal ini memvalidasi kepemilikan Anda atas domain target dan memicu penerbitan sertifikat otomatis:

Jalankan perintah verifikasi manual:

certbot certonly \
  --manual \
  --preferred-challenges dns \
  --key-type rsa \
  --rsa-key-size 2048 \
  --config-dir ./certbot/config \
  --work-dir ./certbot/work \
  --logs-dir ./certbot/logs \
  --server https://${EJBCA_HOSTNAME}/ejbca/acme/${ACME_ALIAS}/directory \
  -d test.${EJBCA_DNS_ZONE}

Terminal akan berhenti dan menampilkan nilai tantangan. Contoh output:

Please deploy a DNS TXT record under the name:

_acme-challenge.test.example.internal.

with the following value:

q3pCmzXfIhsTpT4f4JAulHmHaAR3udC_9Wf1G498ER0

Before continuing, verify the TXT record has been deployed.

Deploy data TXT ke DNS global Anda dengan string yang disediakan oleh Certbot.

Tunggu sekitar 30 detik agar propagasi DNS selesai, kembali ke terminal Certbot, lalu tekan Enter.

Contoh output:

Successfully received certificate.
Certificate is saved at:./certbot/config/live/test.example.internal/fullchain.pem
Key is saved at:./certbot/config/live/test.example.internal/privkey.pem
This certificate expires on 2026-11-16.
These files will be updated when the certificate renews.

Pastikan sertifikat berhasil ditulis ke ./certbot/config/live/test.${EJBCA_DNS_ZONE}/.

Penerapan referensi EJBCA Keyfactor Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.