Cert Manager Application SSL Certificate Process and Related Concepts - III

Chinese and English comparison table

English	English - K8S CRD	Chinese	Notes
certificates	Certificate	Certificate	certificates.cert-manager.io/v1
certificate issuers	Issuer	Certificate issuer	issuers.cert-manager.io
	ClusterIssuer	Cluster Certificate Issuer	clusterissuers.cert-manager.io
certificate request	CertificateRequest	Certificate Request	certificaterequests.cert-manager.io
order	Order	(Certificate) Order	orders.acme.cert-manager.io
challenge	Challenge	(Certificate) Challenge	challenges.acme.cert-manager.io
SelfSigned		Self-signed	A type of cert-manager Issuer
CA		Certificate Authority	Short for Certificate Authority; A type of cert-manager Issuer
Vault		Vault	A type of cert-manager Issuer, the Hashicorp Vault
Venafi			Venafi Online certificate processing services, currently not used much
External		External	A type of cert-manager Issuer
ACME		Automated Certificate Management Environment	Abbreviation for Automated Certificate Management Environment; cert-manager Issuer, including HTTP01 and DNS01

The book continues from the previous one, Finally, let’s understand the related concepts of cert-manager.

Related concepts

Issuer

Issuers and ClusterIssuers is a Kubernetes CRD, which stands for Certificate Authority (CA) and is able to generate a signing certificate by honoring a certificate signing request. All cert-manager certificates require a referenced issuer that is ready to attempt to honor the request.

Issuer An example of a type is “CA”. A simple oneCA IssuerAs follows.

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: ca-issuer
  namespace: mesh-system
spec:
  ca:
    secretName: ca-key-pair

It’s a simple oneIssuer, according to the private key (the private key is stored in the secretca-key-pair) sign the certificate.

• Issuer: Resources limited to a NameSpace;
• ClusterIssuer: Can be used to issue “certificates” in all namespaces.

Certificate

cert-manager has Certificate defines the required X.509 certificate, which will be updated and kept up to date. One Certificate is a Kubernetes CRD that references one Issuer or ClusterIssuer, which determines what will be granted to the certificate request.

When one Certificate When created, a corresponding one CertificateRequest The resource is created by cert-manager and contains the encoded X.509 certificate request.Issuer reference, and other based on 证书 Options for resource specifications.

This one Certificate It tells cert-manager which one to try using Issuer to get the certificate-key pair for the domain name. If successful, the resulting TLS key and certificate will be saved in a secret with the keytls.keyandtls.crt。 This Secret will be withCertificate CRDs are in the same namespace. Examples are as follows:

When the certificate is signed by an intermediate CA, andIssuer When a signed certificate chain can be provided,tls.crtThe content will be the requested certificate, followed by the certificate chain.

Also, if the certificate authority is known, the corresponding CA certificate will be stored in the secret with the keyca.crt。 For example, for the ACME issuer, the CA is not aware of it.ca.crtwill not existacme-crt-secretMiddle.

cert-manager intentionally avoids intls.crtbecause they are useless in the case of secure TLS.

When you configure a client to connect to a TLS server with a service certificate signed by a private CA, you need to provide the CA certificate to the client so that it can authenticate the server.

dnsNamesThe field specifies the certificate-related SAN of lists.

Certificate lifecycle

This image shows the name of the ACME/Let’s Encrypt Issuer usedcert-1The lifecycle of the certificate.

CertificateRequest

CertificateRequestis a Kubernetes CRD in cert-manager that is used to provide a new version to the Kubernetes CRD Issuer Request an X.509 certificate. The resource contains a Base64-encoded, EM-encoded certificate request string that is sent to the referenced issuer. A successful signing will return a signing certificate based on the certificate signing request.CertificateRequestsTypically consumed and managed by controllers or other systems, it should not be used by humans – unless specifically needed.

CertificateRequesttargetspecAll fields, as well as any managed cert-manager comments, are immutable and cannot be modified after creation.

Successful signing of a certificate signing request will result in an update to the resource, with the signed certificate, the certificate’s CA (if available) setting status, and the status Ready The condition is set to True。 As shown in the following figure:

The retry of signing the certificate is regardless of whether the signing request was successfully signedNoHappen. manageCertificateRequestsThe logic and lifecycle of the controller is the responsibility of the other controllers.

condition

CertificateRequests There is a strongly defined set of conditions that the controller or service should use and rely on to decide what action to take on the resource next.

Ready

Each prepared condition consists of a pairReady–A boolean, and Reason–A string composition. This set of values and meanings is as follows:

Ready	Reason	Condition meaning
False	Pending	CertificateRequestIt is currently waiting for other operations to occur. This may be due to:Issuer'还不存在，或者Issuer’ is issuing certificates.
False	Failed	Certificate failed to be signed – either the returned certificate failed to be decoded or the instance of the reference issuer used for signing failed. Its controller will not be rightCertificateRequestTake further action
True	Issued	The referenced Issuer has successfully issued a signed certificate.

ACME Orders and Challenges

cert-manager supports requesting certificates from ACME servers, including from Let’s Encryptuse ACME Issuer。 These certificates are usually trusted by most computers on the public internet. In order to successfully apply for a certificate, cert-manager must solve ACME challenges that are completed to prove that the customer has the requested DNS address.

To accomplish these challenges, cert-manager introduces two CRD types:Orders and Challenges。

Orders

OrdersResources are used by ACME issuers to manage the lifecycle of ACME ‘orders’ to obtain signed TLS certificates. More details on ACME orders and domain verification can be found on the Let’s Encrypt website Over here Found it. An order represents a single certificate request, once a new one CertificateRequest The resource references the ACME issuer and the order is automatically created. once Certificate Resources are created, specifications change, or need to be updated,CertificateRequestResources are automatically created by cert-manager.

As an end user, you will never need to create one manually Order Resource. Once created,Order It cannot be changed. Instead, a new one must be created OrderResource.

Order The resource encapsulates multiple ACMEs for that “order” Challenge, so one or more will be managed Challenge Resource.

Challenges

Challenges Resources are used by ACME publishers to manage the lifecycle of ACME challenges, which must be completed in order to “authenticate” a DNS name/identity.

When one Order When a resource is created, the order controller is created for each DNS name that is being authenticated by the ACME server ChallengeResource.

As an end user, you never need to create one manually Challenge Resource. Once created,ChallengeIt cannot be changed. Instead, a new one must be created ChallengeResource.

Challenge lifecycle

at Challenges Once a resource is created, it is initially queued for processing. Processing will not begin until the challenge is “scheduled” to start. This scheduling process prevents too many challenges being tried at once, or multiple challenges to the same DNS name at once.

Once a challenge is scheduled, it will first be “synchronized” with the ACME server to determine its current state. If the challenge is already valid, it’s status will be updated to valid, and will also be setstatus.processing = falseto “Cancel plan”.

If the challenge is still “pending”, the challenge controller will use the configured workaround (HTTP01 or DNS01) “present” challenge. Once the challenge is “presented”, it will be setstatus.presented = true。

Once “present”, the challenge controller will perform a “self check” to ensure that the challenge has been “propagated” (i.e. the authoritative DNS server has been updated to respond correctly, or changes in ingress resources have been observed and in use by the ingress controller).

If the self-test fails, cert-manager retries the self-test at a fixed 10-second retry interval. Challenges that do not complete the self-introspection will continue to retry until the user intervenes by retrying the Order (by deleting the Order resource) or modifying the relevant Certificate resource to resolve any configuration errors.

Once the self-test passes, the ACME “authorization” associated with this challenge will be “accepted”.

The final status after acceptance of the certification will be copied to the challenge’sstatus.state field, if an error occurs when the ACME server tries to validate the challenge, “error reason” is also copied.

Once the challenge comes in valid、invalid、expired or revoked (Undo) status, it will be set status.processing = falseto prevent any further processing of the ACME challenge, and to allow another challenge to be scheduled if there is a backlog of challenges to complete.

Challenge scheduling

cert-manager does not attempt to handle all challenges at once, but rather “schedules” challenges.

This scheduler sets an upper limit on the maximum number of simultaneous challenges and does not allow the same DNS name and solver type (HTTP01orDNS01Both challenges are completed at the same time.

The maximum number of challenges that can be processed at one time is 60, for the reason ddff78

Series of articles

• cert-manager TAG

📚️ Reference documentation

• cert-manager - cert-manager Documentation
• Use cert-manager to issue a free certificate for dnspod’s domain name Kubernetes Learning Notes (imroc.cc)