cert-manager 1.0 ປ່ອຍອອກມາເມື່ອ

ຖ້າທ່ານຖາມວິສະວະກອນທີ່ມີປະສົບການ, ສະຫລາດວ່າລາວຄິດແນວໃດກ່ຽວກັບຜູ້ຈັດການໃບຢັ້ງຢືນແລະເປັນຫຍັງທຸກຄົນໃຊ້ມັນ, ຜູ້ຊ່ຽວຊານຈະຖອນຫາຍໃຈ, ກອດລາວຢ່າງເປັນຄວາມລັບແລະເວົ້າຢ່າງອິດເມື່ອຍ: "ທຸກຄົນໃຊ້ມັນ, ເພາະວ່າບໍ່ມີທາງເລືອກທີ່ສຸພາບ. ຫນູຂອງພວກເຮົາຮ້ອງໄຫ້, prick ຕົນເອງ, ແຕ່ສືບຕໍ່ດໍາລົງຊີວິດກັບ cactus ນີ້. ເປັນຫຍັງພວກເຮົາຮັກ? ເນື່ອງຈາກວ່າມັນເຮັດວຽກ. ເປັນຫຍັງພວກເຮົາບໍ່ຮັກ? ເນື່ອງຈາກວ່າສະບັບໃຫມ່ໄດ້ຖືກປ່ອຍອອກມາຢ່າງຕໍ່ເນື່ອງທີ່ໃຊ້ຄຸນສົມບັດໃຫມ່. ແລະທ່ານຕ້ອງປັບປຸງກຸ່ມເທື່ອແລ້ວຊ້ຳອີກ. ແລະສະບັບເກົ່າຢຸດເຮັດວຽກ, ເພາະວ່າມີການສົມຮູ້ຮ່ວມຄິດແລະ shamanism ລຶກລັບທີ່ຍິ່ງໃຫຍ່."

ແຕ່ນັກພັດທະນາອ້າງວ່າມີ cert-manage 1.0 ທຸກສິ່ງທຸກຢ່າງຈະປ່ຽນແປງ.

ພວກເຮົາຈະເຊື່ອມັນບໍ?

Cert-manager ເປັນຕົວຄວບຄຸມການຈັດການໃບຮັບຮອງ Kubernetes ພື້ນເມືອງ. ມັນສາມາດຖືກນໍາໃຊ້ເພື່ອອອກໃບຢັ້ງຢືນຈາກແຫຼ່ງຕ່າງໆ: Let's Encrypt, HashiCorp Vault, Venafi, ການລົງນາມແລະຄູ່ທີ່ສໍາຄັນທີ່ເຊັນດ້ວຍຕົນເອງ. ມັນຍັງຊ່ວຍໃຫ້ທ່ານສາມາດຮັກສາລະຫັດໄດ້ທັນສະໄຫມແລະພະຍາຍາມຕໍ່ອາຍຸໃບຢັ້ງຢືນໂດຍອັດຕະໂນມັດໃນເວລາທີ່ກໍານົດໄວ້ກ່ອນທີ່ມັນຈະຫມົດອາຍຸ. Cert-manager ແມ່ນອີງໃສ່ kube-lego, ແລະຍັງໄດ້ນໍາໃຊ້ເຕັກນິກບາງຢ່າງຈາກໂຄງການທີ່ຄ້າຍຄືກັນອື່ນໆ, ເຊັ່ນ kube-cert-manager.

ບັນທຶກການປ່ອຍ

ດ້ວຍສະບັບ 1.0 ພວກເຮົາວາງສັນຍານຄວາມໄວ້ວາງໃຈໃນສາມປີຂອງການພັດທະນາໂຄງການຜູ້ຈັດການໃບຢັ້ງຢືນ. ໃນລະຫວ່າງເວລານີ້, ມັນໄດ້ພັດທະນາຢ່າງຫຼວງຫຼາຍໃນການເຮັດວຽກແລະຄວາມຫມັ້ນຄົງ, ແຕ່ສ່ວນໃຫຍ່ແມ່ນຢູ່ໃນຊຸມຊົນ. ມື້ນີ້ພວກເຮົາເຫັນຫຼາຍຄົນໃຊ້ມັນເພື່ອຮັບປະກັນກຸ່ມ Kubernetes ຂອງເຂົາເຈົ້າ, ເຊັ່ນດຽວກັນກັບການປະຕິບັດມັນເຂົ້າໄປໃນພາກສ່ວນຕ່າງໆຂອງລະບົບນິເວດ. ຊໍ່ຂອງແມງໄມ້ໄດ້ຖືກແກ້ໄຂໃນ 16 ທີ່ຜ່ານມາ. ແລະສິ່ງທີ່ຄວນຖືກແຍກແມ່ນແຕກຫັກ. ການຢ້ຽມຢາມ API ຫຼາຍຄັ້ງປັບປຸງການໂຕ້ຕອບກັບຜູ້ໃຊ້. ພວກເຮົາໄດ້ແກ້ໄຂ 1500 ບັນຫາໃນ GitHub, ດ້ວຍການຮ້ອງຂໍດຶງຫຼາຍຂຶ້ນຈາກສະມາຊິກຊຸມຊົນ 253 ຄົນ.

ໂດຍການປ່ອຍ 1.0 ພວກເຮົາປະກາດຢ່າງເປັນທາງການວ່າຜູ້ຈັດການໃບຢັ້ງຢືນເປັນໂຄງການທີ່ແກ່ແລ້ວ. ພວກເຮົາຍັງສັນຍາວ່າຈະຮັກສາ API ຂອງພວກເຮົາໃຫ້ເຂົ້າກັນໄດ້ v1.

ຂອບໃຈທຸກຄົນທີ່ຊ່ວຍພວກເຮົາສ້າງ cert-manage ທັງສາມປີນີ້! ໃຫ້ເວີຊັນ 1.0 ເປັນອັນທຳອິດຂອງສິ່ງດີໆທີ່ຈະມາເຖິງ.

ການປ່ອຍ 1.0 ເປັນການປ່ອຍທີ່ຫມັ້ນຄົງທີ່ມີຫຼາຍຂົງເຂດບູລິມະສິດ:

• v1 API;

• ທີມງານ kubectl cert-manager status, ເພື່ອຊ່ວຍວິເຄາະບັນຫາ;

• ການນໍາໃຊ້ APIs Kubernetes ທີ່ຫມັ້ນຄົງຫລ້າສຸດ;

• ການປັບປຸງການຕັດໄມ້;

• ການປັບປຸງ ACME.

ໃຫ້ແນ່ໃຈວ່າໄດ້ອ່ານບັນທຶກການປັບປຸງກ່ອນທີ່ຈະຍົກລະດັບ.

API v1

ເວີຊັນ v0.16 ໃຊ້ໄດ້ກັບ API v1beta1. ນີ້ໄດ້ເພີ່ມບາງການປ່ຽນແປງໂຄງສ້າງແລະຍັງປັບປຸງເອກະສານພາກສະຫນາມ API. ເວີຊັ່ນ 1.0 ສ້າງທັງໝົດນີ້ດ້ວຍ API v1. API ນີ້ແມ່ນຄວາມຫມັ້ນຄົງທໍາອິດຂອງພວກເຮົາ, ໃນເວລາດຽວກັນພວກເຮົາໄດ້ໃຫ້ການຄໍ້າປະກັນຄວາມເຂົ້າກັນໄດ້ແລ້ວ, ແຕ່ກັບ API v1 ພວກເຮົາສັນຍາວ່າຈະຮັກສາຄວາມເຂົ້າກັນໄດ້ສໍາລັບປີຂ້າງຫນ້າ.

ການ​ປ່ຽນ​ແປງ​ທີ່​ເຮັດ​ໄດ້ (ຫມາຍ​ເຫດ​: ເຄື່ອງ​ມື​ການ​ປ່ຽນ​ແປງ​ຂອງ​ພວກ​ເຮົາ​ຈະ​ດູ​ແລ​ຂອງ​ທຸກ​ສິ່ງ​ທຸກ​ຢ່າງ​ສໍາ​ລັບ​ທ່ານ​)​:

ໃບຢັ້ງຢືນ:

• emailSANs ດຽວນີ້ເອີ້ນວ່າ emailAddresses

• uriSANs - uris

ການປ່ຽນແປງເຫຼົ່ານີ້ເພີ່ມຄວາມເຂົ້າກັນໄດ້ກັບ SANs ອື່ນໆ (ຊື່ alt ຫົວຂໍ້, ປະມານ ນັກແປ), ເຊັ່ນດຽວກັນກັບ Go API. ພວກເຮົາກໍາລັງຖອນຄໍາສັບນີ້ອອກຈາກ API ຂອງພວກເຮົາ.

ປັບປຸງໃຫ້ທັນ

ຖ້າທ່ານກໍາລັງໃຊ້ Kubernetes 1.16+ - ການແປງ webhooks ຈະຊ່ວຍໃຫ້ທ່ານສາມາດເຮັດວຽກກັບສະບັບ API ພ້ອມກັນແລະ seamlessly. v1alpha2, v1alpha3, v1beta1 и v1. ກັບພວກເຂົາ, ທ່ານສາມາດນໍາໃຊ້ API ຮຸ່ນໃຫມ່ໂດຍບໍ່ມີການປ່ຽນແປງຫຼືນໍາໃຊ້ຊັບພະຍາກອນເກົ່າຂອງທ່ານຄືນໃຫມ່. ພວກເຮົາແນະນໍາໃຫ້ຍົກລະດັບ manifests ຂອງທ່ານເປັນ API v1ຍ້ອນວ່າສະບັບກ່ອນໜ້າຈະຖືກຍົກເລີກໃນໄວໆນີ້. ຜູ້ໃຊ້ legacy ລຸ້ນຂອງ cert-manage ຈະຍັງຄົງມີການເຂົ້າເຖິງເທົ່ານັ້ນ v1, ຂັ້ນຕອນການປັບປຸງສາມາດພົບໄດ້ ທີ່ນີ້.

ຄໍາສັ່ງສະຖານະ cert-manager kubectl

ມີການປັບປຸງໃຫມ່ໃນສ່ວນຂະຫຍາຍຂອງພວກເຮົາເພື່ອ kubectl ມັນໄດ້ກາຍເປັນງ່າຍຕໍ່ການສືບສວນບັນຫາທີ່ກ່ຽວຂ້ອງກັບການບໍ່ອອກໃບຢັ້ງຢືນ. kubectl cert-manager status ໃນປັດຈຸບັນໃຫ້ຂໍ້ມູນເພີ່ມເຕີມກ່ຽວກັບສິ່ງທີ່ເກີດຂຶ້ນກັບໃບຢັ້ງຢືນ, ແລະຍັງສະແດງໃຫ້ເຫັນຂັ້ນຕອນທີ່ໃບຢັ້ງຢືນຖືກອອກ.

ຫຼັງຈາກການຕິດຕັ້ງສ່ວນຂະຫຍາຍທ່ານສາມາດດໍາເນີນການໄດ້ kubectl cert-manager status certificate <имя-сертификата>, ເຊິ່ງຈະຄົ້ນຫາໃບຢັ້ງຢືນທີ່ມີຊື່ທີ່ລະບຸໄວ້ແລະຊັບພະຍາກອນທີ່ກ່ຽວຂ້ອງ, ເຊັ່ນ CertificateRequest, Secret, Issuer, ແລະຄໍາສັ່ງແລະສິ່ງທ້າທາຍໃນກໍລະນີຂອງໃບຢັ້ງຢືນຈາກ ACME.

ຕົວຢ່າງຂອງການດີບັກໃບຮັບຮອງທີ່ຍັງບໍ່ທັນພ້ອມ:

$ kubectl cert-manager status certificate acme-certificate

Name: acme-certificate
Namespace: default
Created at: 2020-08-21T16:44:13+02:00
Conditions:
  Ready: False, Reason: DoesNotExist, Message: Issuing certificate as Secret does not exist
  Issuing: True, Reason: DoesNotExist, Message: Issuing certificate as Secret does not exist
DNS Names:
- example.com
Events:
  Type    Reason     Age   From          Message
  ----    ------     ----  ----          -------
  Normal  Issuing    18m   cert-manager  Issuing certificate as Secret does not exist
  Normal  Generated  18m   cert-manager  Stored new private key in temporary Secret resource "acme-certificate-tr8b2"
  Normal  Requested  18m   cert-manager  Created new CertificateRequest resource "acme-certificate-qp5dm"
Issuer:
  Name: acme-issuer
  Kind: Issuer
  Conditions:
    Ready: True, Reason: ACMEAccountRegistered, Message: The ACME account was registered with the ACME server
error when finding Secret "acme-tls": secrets "acme-tls" not found
Not Before: <none>
Not After: <none>
Renewal Time: <none>
CertificateRequest:
  Name: acme-certificate-qp5dm
  Namespace: default
  Conditions:
    Ready: False, Reason: Pending, Message: Waiting on certificate issuance from order default/acme-certificate-qp5dm-1319513028: "pending"
  Events:
    Type    Reason        Age   From          Message
    ----    ------        ----  ----          -------
    Normal  OrderCreated  18m   cert-manager  Created Order resource default/acme-certificate-qp5dm-1319513028
Order:
  Name: acme-certificate-qp5dm-1319513028
  State: pending, Reason:
  Authorizations:
    URL: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/97777571, Identifier: example.com, Initial State: pending, Wildcard: false
Challenges:
- Name: acme-certificate-qp5dm-1319513028-1825664779, Type: DNS-01, Token: J-lOZ39yNDQLZTtP_ZyrYojDqjutMAJOxCL1AkOEZWw, Key: U_W3gGV2KWgIUonlO2me3rvvEOTrfTb-L5s0V1TJMCw, State: pending, Reason: error getting clouddns service account: secret "clouddns-accoun" not found, Processing: true, Presented: false

ທີມງານຍັງສາມາດຊ່ວຍໃຫ້ທ່ານຮຽນຮູ້ເພີ່ມເຕີມກ່ຽວກັບເນື້ອໃນຂອງໃບຢັ້ງຢືນ. ລາຍລະອຽດຕົວຢ່າງຂອງໃບຢັ້ງຢືນທີ່ອອກໃຫ້ໂດຍ Letsencrypt:

$ kubectl cert-manager status certificate example
Name: example
[...]
Secret:
  Name: example
  Issuer Country: US
  Issuer Organisation: Let's Encrypt
  Issuer Common Name: Let's Encrypt Authority X3
  Key Usage: Digital Signature, Key Encipherment
  Extended Key Usages: Server Authentication, Client Authentication
  Public Key Algorithm: RSA
  Signature Algorithm: SHA256-RSA
  Subject Key ID: 65081d98a9870764590829b88c53240571997862
  Authority Key ID: a84a6a63047dddbae6d139b7a64565eff3a8eca1
  Serial Number: 0462ffaa887ea17797e0057ca81d7ba2a6fb
  Events:  <none>
Not Before: 2020-06-02T04:29:56+02:00
Not After: 2020-08-31T04:29:56+02:00
Renewal Time: 2020-08-01T04:29:56+02:00
[...]

ນຳໃຊ້ APIs Kubernetes ທີ່ໝັ້ນຄົງຫຼ້າສຸດ

Cert-manager ແມ່ນຫນຶ່ງໃນບັນດາຜູ້ທໍາອິດທີ່ປະຕິບັດ Kubernetes CRDs. ນີ້, ບວກກັບການສະຫນັບສະຫນູນຂອງພວກເຮົາສໍາລັບ Kubernetes ຮຸ່ນເຖິງ 1.11, ຫມາຍຄວາມວ່າພວກເຮົາຕ້ອງການສະຫນັບສະຫນູນມໍລະດົກ. apiextensions.k8s.io/v1beta1 ສໍາລັບ CRDs ຂອງພວກເຮົາເຊັ່ນກັນ admissionregistration.k8s.io/v1beta1 ສໍາລັບ webhooks ຂອງພວກເຮົາ. ດຽວນີ້ສິ່ງເຫຼົ່ານີ້ຖືກຍົກເລີກ ແລະຈະຖືກລຶບອອກໃນ Kubernetes ເວີຊັນ 1.22. ດ້ວຍ 1.0 ຂອງພວກເຮົາ, ພວກເຮົາສະເຫນີການສະຫນັບສະຫນູນຢ່າງເຕັມທີ່ apiextensions.k8s.io/v1 и admissionregistration.k8s.io/v1 ສໍາລັບ Kubernetes 1.16 (ບ່ອນທີ່ພວກມັນຖືກເພີ່ມ) ແລະຕໍ່ມາ. ສໍາລັບຜູ້ໃຊ້ຂອງຮຸ່ນທີ່ຜ່ານມາ, ພວກເຮົາສືບຕໍ່ສະຫນອງການສະຫນັບສະຫນູນ v1beta1 ໃນຂອງພວກເຮົາ legacy ສະບັບ.

ການປັບປຸງການບັນທຶກ

ໃນສະບັບນີ້ພວກເຮົາໄດ້ປັບປຸງຫ້ອງສະຫມຸດບັນທຶກເປັນ klog/v2, ໃຊ້ໃນ Kubernetes 1.19. ພວກເຮົາຍັງທົບທວນທຸກໆວາລະສານທີ່ພວກເຮົາຂຽນເພື່ອຮັບປະກັນວ່າມັນຖືກມອບຫມາຍໃນລະດັບທີ່ເຫມາະສົມ. ພວກເຮົາໄດ້ຖືກນໍາພາໂດຍນີ້ ຄໍາແນະນໍາຈາກ Kubernetes. ມີຫ້າ (ໃນຄວາມເປັນຈິງ - ຫົກ, ປະມານ ນັກແປ) ລະດັບການບັນທຶກເລີ່ມຕົ້ນຈາກ Error (ລະດັບ 0), ເຊິ່ງພິມພຽງແຕ່ຄວາມຜິດພາດທີ່ສໍາຄັນ, ແລະສິ້ນສຸດດ້ວຍ Trace (ລະດັບ 5), ເຊິ່ງຈະຊ່ວຍໃຫ້ທ່ານຊອກຫາສິ່ງທີ່ແນ່ນອນເກີດຂຶ້ນ. ດ້ວຍການປ່ຽນແປງນີ້, ພວກເຮົາໄດ້ຫຼຸດລົງຈໍານວນບັນທຶກຖ້າທ່ານບໍ່ຕ້ອງການຂໍ້ມູນການດີບັກໃນເວລາແລ່ນ cert-manager.

ເຄັດ​ລັບ​: ໂດຍ​ຄ່າ​ເລີ່ມ​ຕົ້ນ​ຜູ້​ຈັດ​ການ cert ແລ່ນ​ຢູ່​ໃນ​ລະ​ດັບ 2 (Info), ທ່ານສາມາດ override ນີ້ໂດຍໃຊ້ global.logLevel ໃນຕາຕະລາງ Helm.

ຫມາຍເຫດ: ການທົບທວນຄືນບັນທຶກແມ່ນທາງເລືອກສຸດທ້າຍຂອງທ່ານໃນເວລາທີ່ແກ້ໄຂບັນຫາ. ສໍາລັບຂໍ້ມູນເພີ່ມເຕີມກວດເບິ່ງຂອງພວກເຮົາ ຄວາມເປັນຜູ້ນໍາ.

NB ຂອງບັນນາທິການ: ເພື່ອຮຽນຮູ້ເພີ່ມເຕີມກ່ຽວກັບວິທີການເຮັດວຽກທັງຫມົດພາຍໃຕ້ການປົກຫຸ້ມຂອງ Kubernetes, ຂໍຄໍາແນະນໍາທີ່ມີຄຸນຄ່າຈາກຄູຝຶກສອນ, ເຊັ່ນດຽວກັນກັບການສະຫນັບສະຫນູນດ້ານວິຊາການທີ່ມີຄຸນນະພາບສູງ, ທ່ານສາມາດເຂົ້າຮ່ວມໃນຫຼັກສູດທີ່ເຂັ້ມຂຸ້ນອອນໄລນ໌. ຖານ Kubernetes, ເຊິ່ງຈະຈັດຂຶ້ນໃນເດືອນກັນຍາ 28-30, ແລະ Kubernetes Megaເຊິ່ງຈະຈັດຂຶ້ນໃນວັນທີ 14-16 ຕຸລານີ້.

ການປັບປຸງ ACME

ການນໍາໃຊ້ທົ່ວໄປທີ່ສຸດຂອງຜູ້ຈັດການໃບຢັ້ງຢືນແມ່ນອາດຈະກ່ຽວຂ້ອງກັບການອອກໃບຢັ້ງຢືນຈາກ Let's Encrypt ໂດຍໃຊ້ ACME. ຮຸ່ນ 1.0 ເປັນທີ່ໂດດເດັ່ນສໍາລັບການນໍາໃຊ້ຄໍາຕິຊົມຂອງຊຸມຊົນເພື່ອເພີ່ມການປັບປຸງຂະຫນາດນ້ອຍແຕ່ສໍາຄັນສອງອັນໃຫ້ກັບຜູ້ອອກ ACME ຂອງພວກເຮົາ.

ປິດການສ້າງລະຫັດບັນຊີ

ຖ້າທ່ານໃຊ້ໃບຢັ້ງຢືນ ACME ໃນປະລິມານຫຼາຍ, ທ່ານອາດຈະໃຊ້ບັນຊີດຽວກັນຢູ່ໃນຫຼາຍກຸ່ມ, ດັ່ງນັ້ນຂໍ້ຈໍາກັດການອອກໃບຢັ້ງຢືນຂອງທ່ານຈະນໍາໃຊ້ກັບພວກມັນທັງຫມົດ. ອັນນີ້ເປັນໄປໄດ້ໃນຕົວຈັດການໃບຢັ້ງຢືນເມື່ອສຳເນົາຄວາມລັບທີ່ລະບຸໄວ້ໃນ privateKeySecretRef. ກໍລະນີການນໍາໃຊ້ນີ້ແມ່ນຂ້ອນຂ້າງ buggy ເນື່ອງຈາກວ່າ cert-manager ພະຍາຍາມທີ່ຈະເປັນປະໂຫຍດແລະມີຄວາມສຸກສ້າງລະຫັດບັນຊີໃຫມ່ຖ້າຫາກວ່າມັນບໍ່ສາມາດຊອກຫາໄດ້. ນັ້ນແມ່ນເຫດຜົນທີ່ພວກເຮົາເພີ່ມ disableAccountKeyGenerationເພື່ອປົກປ້ອງທ່ານຈາກພຶດຕິກໍານີ້ໂດຍການຕັ້ງຄ່າທາງເລືອກນີ້ true - cert-manager ຈະບໍ່ສ້າງລະຫັດແລະຈະເຕືອນທ່ານວ່າມັນບໍ່ໄດ້ຖືກໃຫ້ລະຫັດບັນຊີ.

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt
spec:
  acme:
    privateKeySecretRef:
      name: example-issuer-account-key
    disableAccountKeyGeneration: false

ລະບົບຕ່ອງໂສ້ທີ່ຕ້ອງການ

ເດືອນກັນຍາ 29 ໃຫ້ເຂົ້າລະຫັດ ຈະຍ້າຍອອກ ກັບອຳນາດການຢັ້ງຢືນຮາກຂອງເຈົ້າເອງ ISRG Root. ໃບຮັບຮອງທີ່ມີລາຍເຊັນຈະຖືກແທນທີ່ດ້ວຍ Identrust. ການປ່ຽນແປງນີ້ບໍ່ຮຽກຮ້ອງໃຫ້ມີການປ່ຽນແປງການຕັ້ງຄ່າຜູ້ຈັດການໃບຢັ້ງຢືນ;

ໃຫ້ເຂົ້າລະຫັດໃບຮັບຮອງແລ້ວກັບ CA ນີ້ ແລະສະເໜີໃຫ້ພວກມັນເປັນ "ຕ່ອງໂສ້ໃບຢັ້ງຢືນສຳຮອງ" ຜ່ານ ACME. ເວີຊັ່ນນີ້ຂອງ cert-manager ມີຄວາມສາມາດໃນການກໍານົດການເຂົ້າເຖິງຕ່ອງໂສ້ເຫຼົ່ານີ້ຢູ່ໃນການຕັ້ງຄ່າຜູ້ອອກ. ໃນພາລາມິເຕີ preferredChain ທ່ານສາມາດລະບຸຊື່ຂອງ CA ທີ່ໃຊ້ໃນການອອກໃບຢັ້ງຢືນ. ຖ້າໃບຮັບຮອງ CA ມີທີ່ກົງກັບຄໍາຮ້ອງຂໍ, ມັນຈະອອກໃບຢັ້ງຢືນໃຫ້ທ່ານ. ກະລຸນາຮັບຊາບວ່ານີ້ແມ່ນທາງເລືອກທີ່ຕ້ອງການ; ນີ້ຈະຮັບປະກັນວ່າທ່ານຍັງຈະຕໍ່ອາຍຸໃບຢັ້ງຢືນຂອງທ່ານຫຼັງຈາກການລຶບລະບົບຕ່ອງໂສ້ທາງເລືອກໃນດ້ານຜູ້ອອກ ACME.

ມື້ນີ້ທ່ານສາມາດໄດ້ຮັບໃບຢັ້ງຢືນທີ່ໄດ້ເຊັນ ISRG Root, ດັ່ງນັ້ນ:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    preferredChain: "ISRG Root X1"

ຖ້າທ່ານຕ້ອງການທີ່ຈະອອກຈາກລະບົບຕ່ອງໂສ້ IdenTrust — ກໍາ​ນົດ​ຕົວ​ກໍາ​ນົດ​ການ​ນີ້​ DST Root CA X3:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    preferredChain: "DST Root CA X3"

ກະລຸນາຮັບຊາບວ່າ root CA ນີ້ຈະຖືກຍົກເລີກໃນໄວໆນີ້, Let's Encrypt ຈະຮັກສາຕ່ອງໂສ້ນີ້ໃຫ້ນຳໃຊ້ໄດ້ຈົນຮອດວັນທີ 29 ກັນຍາ 2021.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com