Issuers

Issuers are Kubernetes resources that represent certificate authorities in a namespace. They can generate trusted certificates by fulfilling certificate signing requests.

On the Issuers page you can create, edit, delete, or view previously created Issuers.

Creating Issuers #

To add an Issuer, click + Add Issuer.

In the dialog that opens, fill in:

• Issuer name
• Object specification type:
  • ACME;
  • Vault;
  • Corporate certificate authority (CA);
  • Self-signed (SelfSigned).

If needed, add labels.

ACME configuration #

To configure ACME, you must have an ACME (Automated Certificate Management Environment) account.

• Fill in ACME server details. For example: https://acme-v02.api.letsencrypt.org/directory
• Enter the email associated with the ACME account.
• Define whether to skip TLS verification.

If you skip TLS verification, requests to the ACME server are not verified with a TLS certificate (that is, insecure connections are allowed). Enable this option only in development environments.

Note! If an ACME certificate is installed in the cluster, monitor the ACME server. If the server fails, clusters with ACME certificates may become unavailable.

• When establishing a secure TLS connection, you can specify a certificate authority bundle in the CA Bundle field. The CA Bundle contains the root and intermediate certificates in PEM format to authenticate and trust ACME server certificates. Note! CA Bundle file data must include ----BEGIN CERTIFICATE---- and ----END CERTIFICATE----.

If CABundle is not specified but TLS verification is enabled, the system certificate bundle inside the container is used to verify the connection.

In the ACME account key block:

• Enter the Secret name and key.
• Add solvers: choose the solver type: HTTP01 or DNS01.

1. For HTTP01, fill in the ClassIngress field and click Add.

This can be used if:

• your provider does not block port 80;
• the Ingress controller is reachable from the internet on port 80;
• you do not use wildcard certificates.

Enter the Ingress class (ClassIngress) that should be used to solve the Let’s Encrypt challenge.

kubectl get ingressclass -A

If ClassIngress is not specified, the default class is used.

2. For DNS01/acmeDNS, fill in the host value. In AccountSecretRef, enter the name and key, then click Add.

This can be used if:

• you use wildcard certificates;
• you have multiple web servers.

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: example-issuer
spec:
  acme:
    solvers:
    - dns01:
        acmeDNS:
          host: https://acme.example.com
          accountSecretRef:
            name: acme-dns
            key: acmedns.json

3. For DNS01/rfc2136, fill in Nameserver and TsigAlgorithm. In TsigSecretSecretRef, enter the name and key, then click Add.

This can be used if you have:

• a DNS server configured with RFC2136 support;
• access to the data (TSIG keys) required to authorize DNS updates.

rfc2136:
         nameserver: 1.2.3.4:53
         tsigKeyName: example-com-secret
         tsigAlgorithm: HMACSHA512
         tsigSecretSecretRef:
           name: tsig-secret
           key: tsig-secret-key

4. For DNS01/webhook, fill in cert-manager data by entering GroupName, SolverName, and Config, then click Add.

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: example-issuer
spec:
  acme:
   ...
    solvers:
    - dns01:
        webhook:
          groupName: $WEBHOOK_GROUP_NAME
          solverName: $WEBHOOK_SOLVER_NAME
          config:
            ...
            <webhook-specific-configuration>

Vault configuration #

To configure Vault, you must have a Vault account. According to the official cert-manager documentation, the recommended integration method for the current version is ServiceAccountRef. For integration, select a ServiceAccount from the drop-down list.

The ServiceAccount must be created in the same namespace and have the vault-issuer role in that namespace with the following permissions:

rules:
  - apiGroups: ['']
    resources: ['serviceaccounts/token']
    resourceNames: ['vault-issuer']
    verbs: ['create']

At present, creating roles and clusterroles from the platform UI is unavailable. To create a role, download the cluster kubeconfig, connect to the cluster from the command line, and apply a manifest with the appropriate role. Created roles appear in the list of available roles when creating a ServiceAccount.

• After selecting a ServiceAccount, in the mountPath field enter the Vault mount path used for Vault authentication. Example: /v1/auth/kubernetes.
• In the Role field, enter the user role on the Vault side, for example: my-app-1.
• In the Path field, enter the path to the mounted Vault PKI backend signing endpoint, for example: my_pki_mount/sign/my-role-name.
• In the Server field, enter the Vault server address, for example: https://vault.local.
• To authenticate and trust Vault server certificates, you can specify a CA Bundle containing root and intermediate certificates in PEM format.

There are two ways to include a CA Bundle in Issuers:

1. Select File in the CA Bundle block to enter CA Bundle file data. Note! CA Bundle file data must include ----BEGIN CERTIFICATE---- and ----END CERTIFICATE----.
2. Select CA Bundle key in the CA Bundle block to load a CA Bundle by referencing a Secret in your cluster. Select the Secret that contains the CA Bundle and specify the key to access it.

If CABundle is not specified in the Issuer, the cert-manager certificate bundle is used to verify the TLS connection.

Corporate certificate authority (CA) #

CA (Certificate Authority) Issuers must be configured with a certificate authority certificate and private key stored in a Secret. Before adding a CA Issuer to the namespace, create a Secret containing the certificate and key.

Note!

• The Secret and Issuer must be in the same namespace.
• In the Secret, the field names for the certificate and key must be exactly tls.crt and tls.key. cert-manager uses these names to read the certificate authority certificate and key data.
• Data in tls.crt and tls.key must be base64-encoded.

apiVersion: v1
kind: Secret
metadata:
  name: secretname
  namespace: namespacename
data:
  tls.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMrVENDQWVHZ0F3SUJBZ0lKQUtQR3dLRGwvNUhuTUEwR0NTcUdTSWIzRFFFQkN3VUFNQk14RVRBUEJnTlYKQkFNTUNHcHZjMmgyWVc1c01CNFhEVEU1TURneU1qRTJNRFUxT0ZvWERUSTVNRGd4T1RFMk1EVTFPRm93RXpFUgpNQThHQTFVRUF3d0lhbTl6YUhaaGJtd3dnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUtBb0lCCkFRQ3doU0IvcVc2L2tMYjJ6cHUrRUp2RDl3SEZhcStRQS8wSkgvTGxseW83ekFGeCtISHErQ09BYmsrQzhCNHQKL0hVRXNuczVSTDA5Q1orWDRqNnBiSkZkS2R1UHhYdTVaVllua3hZcFVEVTd5ZzdPU0tTWnpUbklaNzIzc01zMApSNmpZbi9Ecmo0eFhNSkVmSFVEcVllU1dsWnIzcWkxRUZhMGM3ZlZEeEgrNHh0WnROTkZPakg3YzZEL3ZXa0lnCldRVXhpd3Vzc2U2S01PV2pEbnYvNFZyamVsMlFnVVlVYkhDeWVaSG1jdGkrSzBMV0Nmby9SZzZQdWx3cmJEa2gKam1PZ1l0MzBwZGhYME9aa0F1a2xmVURIZnA4YmpiQ29JMnRhWUFCQTZBS2pLc08zNUxBRVU3OUNMMW1MVkh1WgpBQ0k1VWppamEzVlBXVkhTd21KUEp5dXhBZ01CQUFHalVEQk9NQjBHQTFVZERnUVdCQlFtbDVkVEFaaXhGS2hqCjkzd3VjUldoYW8vdFFqQWZCZ05WSFNNRUdEQVdnQlFtbDVkVEFaaXhGS2hqOTN3dWNSV2hhby90UWpBTUJnTlYKSFJNRUJUQURBUUgvTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElCQVFCK2tsa1JOSlVLQkxYOHlZa3l1VTJSSGNCdgpHaG1tRGpKSXNPSkhac29ZWGRMbEcxcFpORmpqUGFPTDh2aDQ0Vmw5OFJoRVpCSHNMVDFLTWJwMXN1NkNxajByClVHMWtwUkJlZitJT01UNE1VN3ZSSUNpN1VPbFJMcDFXcDBGOGxhM2hQT2NSYjJ5T2ZGcVhYeVpXWGY0dDBCNDUKdEhpK1pDTkhCOUZ4alNSeWNiR1lWaytUS3B2aEphU1lOTUdKM2R4REthUDcrRHgzWGNLNnNBbklBa2h5SThhagpOVSttdzgvdG1Sa1A0SW4va1hBUitSaTBxVW1Iai92d3ZuazRLbTdaVXkxRllIOERNZVM1TmtzbisvdUhsUnhSClY3RG5uMDM5VFJtZ0tiQXFONzJnS05MbzVjWit5L1lxREFZSFlybjk4U1FUOUpEZ3RJL0svQVRwVzhkWAotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
  tls.key: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb3dJQkFBS0NBUUVBc0lVZ2Y2bHV2NUMyOXM2YnZoQ2J3L2NCeFdxdmtBUDlDUi95NVpjcU84d0JjZmh4CjZ2Z2pnRzVQZ3ZBZUxmeDFCTEo3T1VTOVBRbWZsK0krcVd5UlhTbmJqOFY3dVdWV0o1TVdLVkExTzhvT3praWsKbWMwNXlHZTl0N0RMTkVlbzJKL3c2NCtNVnpDUkh4MUE2bUhrbHBXYTk2b3RSQld0SE8zMVE4Ui91TWJXYlRUUgpUb3grM09nLzcxcENJRmtGTVlzTHJMSHVpakRsb3c1Ny8rRmE0M3Bka0lGR0ZHeHdzbm1SNW5MWXZpdEMxZ242ClAwWU9qN3BjSzJ3NUlZNWpvR0xkOUtYWVY5RG1aQUxwSlgxQXgzNmZHNDJ3cUNOcldtQUFRT2dDb3lyRHQrU3cKQkZPL1FpOVppMVI3bVFBaU9WSTRvMnQxVDFsUjBzSmlUeWNyc1FJREFRQUJBb0lCQUNFTkhET3JGdGg1a1RpUApJT3dxa2UvVVhSbUl5MHlNNHFFRndXWXBzcmUxa0FPMkFDWjl4YS96ZDZITnNlanNYMEM4NW9PbmtrTk9mUHBrClcxVS94Y3dLM1ZpRElwSnBIZ09VNzg1V2ZWRXZtU3dZdi9Fb1V3eHFHRVMvcnB5Z1drWU5WSC9XeGZGQlg3clMKc0dmeVltbXJvM09DQXEyLzNVVVFiUjcrT09md3kzSHdUdTBRdW5FSnBFbWU2RXdzdWIwZzhTTGp2cEpjSHZTbQpPQlNKSXJyL1RjcFRITjVPc1h1Vm5FTlVqV3BBUmRQT1NrRFZHbWtCbnkyaVZURElST3NGbmV1RUZ1NitXOWpqCmhlb1hNN2czbkE0NmlLenUzR0YwRWhLOFkzWjRmeE42NERkbWNBWnphaU1vMFJVaktWTFVqbVlQSEUxWWZVK3AKMkNYb3dNRUNnWUVBMTgyaU52UEkwVVlWaUh5blhKclNzd1YrcTlTRStvVi90U2ZSUUNGU2xsV0d3KzYyblRiVwpvNXpoL1RDQW9VTVNSbUFPZ0xKWU1LZUZ1SWdvTEoxN1pvWjN0U1czTlVtMmRpT0lPSHorcTQxQzM5MDRrUzM5CjkrYkFtVmtaSFA5VktLOEMraS9tek5mSkdHZEJadGIweWtTM2t3OUIxTHdnT3o3MDhFeXFSQ2tDZ1lFQTBXWlAKbzF2MThnV2tMK2FnUDFvOE13eDRPZlpTN3dKY3E0Z0xnUWhjYS9pSkttY0x0RFN4cUJHckJ4UVo0WTIyazlzdQpzTFVrNEJobGlVM29iUUJNaUdtMGtITHVBSEFRNmJvdWZBMUJwZjN2VFdHSkhSRjRMeFJsNzc2akw4UXI4VnpxClpURVBtY0R0T0hpYjdwb2I1Z2IzSDhiVGhYeUhmdGZxRW55alhFa0NnWUVBdk9DdDZZclZhTlQrWThjMmRFYk4Kd3dJOExBaUZtdjdkRjZFUjlCODJPWDRCeGR0WTJhRDFtNTNqN2NaVnpzNzFYOE1TN25FcDN1dkFqaElkbDI3KwpZbTJ1dUUyYVhIbDN5VTZ3RzBETFpUcnVIU0Z5TVI4ZithbHRTTXBDd0s1NXluSGpHVFp6dXpYaVBBbWpwRzdmCk1XbVRncE1IK3puc3UrNE9VNFBHUW9FQ2dZQWNqdUdKbS84YzlOd0JsR2lDZTJIK2JGTHhSTURteStHcm16QkcKZHNkMENqOWF3eGI3aXJ3MytjRGpoRUJMWExKcjA5YTRUdHdxbStrdElxenlRTG92V0l0QnNBcjVrRThlTVVBcAp0djBmRUZUVXJ0cXVWaldYNWlaSTNpMFBWS2ZSa1NSK2pJUmVLY3V3aWZKcVJpWkw1dU5KT0NxYzUvRHF3Yk93CnRjTHAwUUtCZ0VwdEw1SU10Sk5EQnBXbllmN0F5QVBhc0RWRE9aTEhNUGRpL2dvNitjSmdpUmtMYWt3eUpjV3IKU25QSG1TbFE0aEluNGMrNW1lbHBDWFdJaklLRCtjcTlxT2xmQmRtaWtYb2RVQ2pqWUJjNnVGQ1QrNWRkMWM4RwpiUkJQOUNtWk9GL0hOcHN0MEgxenhNd1crUHk5Q2VnR3hhZ0ZCekxzVW84N0xWR2h0VFFZCi0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tCg==

For an Issuer of type Corporate certificate authority:

• select the Secret name containing the certificate authority certificate and key.
• add OCSP server URLs (ocspServers) if you need to verify certificate validity (status). If no address is specified, the certificate is issued without an OCSP server reference. Example server URL: http://ocsp.int-x3.example.org.
• add issuing certificate URLs (issuingCertificateURLs) to include in issued certificates. The URL must use HTTP to avoid domain validation issues, for example: http://ca.domain.com/ca.crt.
• if needed, add CRL distribution points (crlDistributionPoints): addresses of certificate revocation lists (Certificate Revocation List, CRL). At the specified addresses (for example, http://example.com) you can check whether issued certificates have been revoked.

Self-signed (SelfSigned) #

Self-signed (SelfSigned) Issuers are used to establish fast, secure connections when certificate authority validation is not required.

When Self-signed is selected for an Issuer, you can optionally add CRL distribution points (CDP) (crlDistributionPoints). Each point (URL, for example, http://example.com) identifies the location of a certificate revocation list (Certificate Revocation List, CRL) where you can verify the validity of issued certificates.

After finishing Issuer configuration, click Save.

Editing Issuers #

To edit an Issuer, open the Issuer view page and change the object specification on the Issuer tab. To change labels, open the Labels tab. Save your changes.

You can also edit an Issuer using a YAML manifest. Open the Manifest tab. After changing the manifest, run validation. The validation result appears on the right side of the screen. Expand the validation result block to see the full manifest. If Issuer manifest format validation fails, manifest validation is unavailable.

Save the changes made to the manifest. Unsaved data will not be applied.

You can delete an Issuer in one of the following ways:

• on the Issuers page, click in the object row;
• on the Issuer view page, on the Issuer tab, click Delete;
• on the Issuer view page, open the Manifest tab and click .