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

Penerapan referensi EJBCA Keyfactor

Ringkasan

Panduan ini membahas integrasi Keyfactor EJBCA Enterprise (di-deploy sebagai peralatan eksternal) sebagai Certificate Authority (CA) pihak ketiga untuk Google Distributed Cloud (GDC) dengan air gap.

Keyfactor EJBCA Enterprise adalah platform Certificate Authority yang sangat skalabel, andal, dan sesuai dengan FIPS yang memungkinkan organisasi mengelola infrastruktur kunci publik (PKI) di berbagai lingkungan yang 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 menstandarkan infrastruktur PKI mereka pada Keyfactor EJBCA untuk workload yang ada di luar GDC mungkin lebih memilih untuk memanfaatkan arsitektur dan kebijakan pengelolaan CA yang 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 Registration Authority (RA).

Asumsi

Sebelum melanjutkan panduan ini, pastikan asumsi berikut terpenuhi:

Keyfactor EJBCA di-deploy sebagai peralatan software atau peralatan hardware, dan alamat IP yang stabil dikonfigurasi untuk layanan tersebut.
Certificate Authority (CA) root, bawahan, dan pengelolaan telah dibuat di instance EJBCA.
Profil End Entity (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 atau apa yang dikonfigurasi di instance EJBCA Anda.

Arsitektur

Arsitektur ini mengikuti model Certificate Authority eksternal, dengan server EJBCA dan Hardware Security Module (HSM) pendukungnya dihosting secara eksternal di luar batas fisik GDC, tetapi dapat diakses melalui jaringan. Server EJBCA dapat di-deploy secara eksternal sebagai perangkat hardware atau software. Integrasi inti yang dijelaskan dalam panduan ini hanya mengharuskan 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 peralatan hardware atau peralatan software Keyfactor, yang menampung CA (Root dan Subordinat) dan menghasilkan semua materi kunci CA di dalam HSM bersertifikasi CC EAL4+.
Cluster Kubernetes Standar GDC: Lingkungan komputasi yang menjalankan workload 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 DNS-01 ACME.
Gateway Egress GDC: Mengarahkan traffic keluar dari pod cluster ke alamat IP server EJBCA eksternal.
Harbor Private Registry: Menghosting image container yang diduplikasi (seperti penerbit cert-manager EJBCA) untuk deployment air-gap.

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.

Konfigurasikan variabel lingkungan yang akan dirujuk di sepanjang panduan ini. Ubah nilai ini sesuai kebutuhan agar sesuai 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 ini 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 mesin tanpa akses internet, Anda harus mendapatkan aset ini secara terpisah (misalnya, menggunakan docker save untuk mengekspor image dari mesin 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 praktis untuk pengelolaan zona dan API global 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"
```

Membuat 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 Container Registry 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 worker node cluster Anda:

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

3 Buat cluster standar dengan dua worker node 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 diduplikasi:

```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 dan setelan jaringan GDC yang mendasarinya. Hal ini memastikan bahwa workload Kubernetes Anda dapat me-resolve 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 zona DNS pribadi dan set data 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 Managed DNS Project Admin ke 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 peralatan 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 egress GDC dengan menyiapkan subnet kustom dan gateway NAT untuk memungkinkan workload Kubernetes (seperti cert-manager dan klien Registration Authority) merutekan traffic keluar dengan aman ke server EJBCA:

Tetapkan peran developer jaringan level 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 egress:

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 dalam container.

Diagram integrasi cert-manager EJBCA.

Mengonfigurasi EJBCA untuk penerbit

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

Membuat profil sertifikat admin

Anda memulai dengan membuat profil sertifikat di dalam EJBCA untuk menentukan properti teknis dan batasan kriptografis (seperti algoritma dan masa berlaku) sertifikat administratif:

Buka UI Admin EJBCA, buka CA Functions > Certificate Profiles.
Buat clone profil ENDUSER dan beri nama GDC ADMIN PROFILE.
Edit GDC ADMIN PROFILE dan konfigurasikan setelan berikut:
- Algoritma Kunci yang Tersedia: RSA
- Panjang Bit yang Tersedia: 2048, 3072, 4096
- Signature Algorithm: SHA512WithRSA
- Validitas: 200d
- Nama Alternatif Penerbit: Penggunaan yang Jelas
- CRL Distribution Points: Centang Use
- Use CA defined CRL Distribution Point: Centang Use
- Authority Information Access: Centang Use
- Use CA defined OCSP locator: Centang Use
- Use CA defined CA issuer: Centang Use
- 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 Add End Entity Profile, masukkan GDC ADMIN EE PROFILE, lalu klik Add Profile.
Edit profil dan konfigurasikan 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, Anda mendaftarkan identitas administratif menggunakan antarmuka Registration Authority (RA) EJBCA dan mengekstrak kunci pribadi, sertifikat publik, dan rantai kepercayaan untuk membuat file kredensial fisik yang diperlukan untuk mengautentikasi cert-manager:

Buka tab RA Web.
Klik Make New Request dan konfigurasikan:
- Certificate Type: GDC ADMIN EE PROFILE
- Pembuatan pasangan kunci: Oleh CA
- Algoritma kunci: RSA 4096 bit
- Common Name (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.
Telusuri entity 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 Access Rules dan konfigurasikan hak istimewa berikut:
- Role Template: RA Administrators
- CA yang diizinkan: GDC Subordinate CA
- Aturan Entity Akhir: Menyetujui, Membuat, dan Mengedit Entity Akhir
- Profil Entity Akhir: GDC TLS SERVER EE PROFILE
- Aturan Lainnya: hapus Lihat Log Audit
Klik Simpan.

Menyiapkan cluster GDC

Untuk menyiapkan lingkungan GDC, lakukan autentikasi dengan cluster Kubernetes standar Anda dan simpan 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 secret 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 menduplikasi image container penerbit cert-manager EJBCA ke registry Harbor pribadi dan men-deploy diagram Helm. Tindakan ini akan membuat instance 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

Duplikasi 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 diduplikasi:

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

Membuat resource penerbit

Selanjutnya, Anda akan menetapkan izin RBAC GDC dan men-deploy resource ClusterIssuer global, yang mendaftarkan server EJBCA sebagai sumber penandatanganan tepercaya di 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 Kubernetes Certificate 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 menggunakan 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 harus mengaktifkan layanan ACME di dalam EJBCA dan mengonfigurasi alias ACME dengan DNS resolver khusus. Tindakan ini akan menyiapkan server EJBCA untuk memproses dan memvalidasi respons verifikasi DNS-01 di dalam GDC:

Di UI Admin EJBCA, buka System Configuration > ACME Configuration.
Klik Add dan konfigurasikan hal berikut:
- Nama: default
- Profil entity akhir: GDC TLS SERVER EE PROFILE
- Penerbitan Sertifikat Karakter Pengganti Diizinkan: Centang
- Jenis tantangan ID DNS Validasi MPIC Respons Tantangan: Pilih dns-01
- DNS resolver: Masukkan IP DNS global Anda.
- Validate DNSSEC: hapus (karena ini adalah lingkungan pribadi lokal)
Klik Simpan.

Membuat 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 akan menginstal klien Certbot standar dan mendaftarkannya ke 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

Mengeluarkan sertifikat menggunakan verifikasi DNS

Terakhir, Anda menjalankan permintaan Certbot manual dan men-deploy resource TXT DNS GDC sementara untuk menyelesaikan verifikasi DNS-01. Tindakan 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 verifikasi. 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 untuk propagasi DNS, 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.