diff --git a/doc/source/deploy/certificates.rst b/doc/source/deploy/certificates.rst
new file mode 100644
index 0000000..f99d4f0
--- /dev/null
+++ b/doc/source/deploy/certificates.rst
@@ -0,0 +1,319 @@
+============
+Certificates
+============
+
+Atmosphere simplifies all the management of your SSL certificates for all of
+your API endpoints by automatically issuing and renewing certificates for you
+using `cert-manager <https://cert-manager.io>`_.
+
+Types
+=====
+
+There are two different ways of issuing certificates.  It can either issue
+individual certificates for each API endpoint or it can issue a wildcard
+certificate for all of your API endpoints.
+
+Individual Certificates
+-----------------------
+
+If you want to issue individual certificates for each API endpoint, you do not
+need to do anything.  This is the default behavior of Atmosphere.
+
+Wildcard Certificate
+--------------------
+
+If you decide to use wildcard certificates, you can either let the certificate
+manager issue and renew the certificate for you or you can use an existing
+wildcard certificate.
+
+Automatically Issued
+~~~~~~~~~~~~~~~~~~~~
+
+If you want to issue a wildcard certificate for all of your API endpoints using
+the certificate manager, you can configure it by setting the the following variable
+in your inventory:
+
+.. code-block:: yaml
+
+  openstack_helm_ingress_wildcard_domain: cloud.atmosphere.dev
+
+This will issue a wildcard certificate for ``*.cloud.atmosphere.dev`` and all
+subdomains.  The certificate manager will automatically renew the certificate
+before it expires.
+
+Existing Certificate
+~~~~~~~~~~~~~~~~~~~~
+
+If you want to use an existing wildcard certificate without relying on the
+certificate manager issuing and renewing the certificate, you can use the
+following steps:
+
+1. Create a Kubernetes TLS secret using your wildcard certificate, you can refer
+   to the `Kubernetes documentation <https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets>`_
+   for more details.
+
+   .. code-block:: shell
+
+     kubectl -n openstack create secret tls wildcard-certs --key=/path/to/tls.key --cert=/path/to/tls.crt
+
+   .. note::
+
+      If you have a certificate that needs to be combined with an intermediate
+      certificate, you can combine them all to a single file with the certificate
+      first, followed by the intermediate certificate, followed by the root.
+
+2. Update the ``openstack_helm_ingress_secret_name`` to point towards the name
+   of the secret you created in step 1.
+
+   .. code-block:: yaml
+
+     openstack_helm_ingress_secret_name: wildcard-certs
+
+3. Set ``cluster_issuer_type`` to ``none``, this is required for other roles
+   like for example Horizon.
+
+   .. code-block:: yaml
+
+     cluster_issuer_type: none
+
+.. warning::
+
+   If you decide to use an existing wildcard certificate, you will need to
+   manually renew the certificate before it expires.
+
+Issuers
+=======
+
+In order to be able to automatically issue certificates, you need to configure
+an issuer.  There are three different types of issuers that you can use with
+Atmosphere.
+
+.. note::
+
+   If you decide to change the certificate issuer after deployment, you will
+   need to delete the existing certificate secret in order for the new issuer
+   to be able to issue a new certificate.
+
+ACME
+----
+
+Atmosphere uses the `ACME <https://tools.ietf.org/html/rfc8555>`_ protocol by
+default to request certificates from `LetsEncrypt <https://letsencrypt.org>`_.
+
+There are two different challenge types that can be used to verify ownership of
+the domain to issue the certificate using ACME.  Regardless of the challenge
+type, you will need to configure an email address to be used for the ACME
+account.
+
+.. code-block:: yaml
+
+  cluster_issuer_type: acme
+  cluster_issuer_acme_email: user@example.com
+
+If you're running your own internal ACME server, you can configure Atmosphere to
+point towards it by setting the ``cluster_issuer_acme_server`` variable.
+
+.. code-block:: yaml
+
+  cluster_issuer_acme_server: https://acme.example.com
+  cluster_issuer_acme_email: user@example.com
+
+If the ACME server is using certificates signed by a custom CA, you can add the
+following configuration to allow Atmosphere to trust the CA.
+
+.. code-block:: yaml
+
+  cluster_issuer_acme_private_ca: true
+
+HTTP-01 Challenge
+~~~~~~~~~~~~~~~~~
+
+This is configured to work out of the box if your APIs are publicly accessible
+since it uses an HTTP-01 challenge to verify ownership of the domain.  You just
+need to configure an email address.
+
+DNS-01 Challenge
+~~~~~~~~~~~~~~~~
+
+Atmosphere uses the ``HTTP-01`` solver by default, which means that as long as
+your ACME server can reach your API, you don't need to do anything else.
+
+If your ACME server cannot reach your API, you will need to use the ``DNS-01``
+challenges which require you to configure your DNS provider.
+
+RFC2136
+*******
+
+If you have a DNS server that supports RFC2136, you can use it to solve the DNS
+challenges with the following configuration:
+
+.. code-block:: yaml
+
+  cluster_issuer_acme_email: user@example.com
+  cluster_issuer_acme_solver: rfc2136
+  cluster_issuer_acme_rfc2136_nameserver: <NAMESERVER>:<PORT>
+  cluster_issuer_acme_rfc2136_tsig_algorithm: <ALGORITHM>
+  cluster_issuer_acme_rfc2136_tsig_key_name: <KEY_NAME>
+  cluster_issuer_acme_rfc2136_tsig_secret_key: <SECRET_KEY>
+
+Route53
+*******
+
+If you are using Route53 to host the DNS for your domains, you can use the
+following configuration:
+
+.. code-block:: yaml
+
+  cluster_issuer_acme_email: user@example.com
+  cluster_issuer_acme_solver: route53
+  cluster_issuer_acme_route53_region: <REGION>
+  cluster_issuer_acme_route53_hosted_zone_id: <HOSTED_ZONE_ID>
+  cluster_issuer_acme_route53_access_key_id: <AWS_ACCESS_KEY_ID>
+  cluster_issuer_acme_route53_secret_access_key: <AWS_SECRET_ACCESS_KEY>
+
+.. note::
+
+   You'll need to make sure that your AWS credentials have the correct
+   permissions to update the Route53 zone.
+
+GoDaddy
+*******
+
+If you're using GoDaddy for the DNS of your domain, you can use the following
+configuration which depends on
+`cert-manager-webhook-godaddy <https://github.com/snowdrop/godaddy-webhook>`_.
+
+.. code-block:: yaml
+
+  cluster_issuer_acme_email: user@example.com
+  cluster_issuer_acme_solver: godaddy
+  cluster_issuer_acme_godaddy_api_key: <GODADDY_API_KEY>
+  cluster_issuer_acme_godaddy_secret_key: <GODADDY_SECRET_KEY>
+
+Infoblox
+********
+
+If you're using Infoblox for the DNS of your domain, you can use the following
+configuration which depends on
+`cert-manager-webhook-infoblox-wapi <https://github.com/luisico/cert-manager-webhook-infoblox-wapi>`_.
+
+.. code-block:: yaml
+
+  cluster_issuer_acme_email: user@example.com
+  cluster_issuer_acme_solver: infoblox
+  cluster_issuer_acme_infoblox_view: <VIEW>
+  cluster_issuer_acme_infoblox_host: <HOST>
+  cluster_issuer_acme_infoblox_username: <USERNAME>
+  cluster_issuer_acme_infoblox_password: <PASSWORD>
+
+Venafi
+------
+
+Venafi is a commercial certificate authority which can be used with Atmosphere
+to issue certificates.  Regardless of the way that you authenticate to Venafi,
+you will need to configure the issuer.
+
+.. code-block:: yaml
+
+  cluster_issuer_type: venafi
+  cluster_issuer_venafi_zone: <ZONE>
+  cluster_issuer_venafi_tpp_url: <URL>
+  cluster_issuer_venafi_tpp_ca_bundle: |
+    -----BEGIN CERTIFICATE-----
+    MIIDBjCCAe4CCQDQ3Z0Z2Z0Z0jANBgkqhkiG9w0BAQsFADCBhTELMAkGA1UEBhMC
+    VVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28x
+    ...
+    -----END CERTIFICATE-----
+
+Authentication
+~~~~~~~~~~~~~~
+
+There are two different ways to authenticate to Venafi to issue certificates,
+either using a username and password or using an access token.  The username and
+password method is phased out in newer versions of Venafi, so it is recommended
+to use the access token method.
+
+Username and Password
+*********************
+
+If you are using a username and password to authenticate to Venafi, you can
+configure it with the following variables:
+
+.. code-block:: yaml
+
+  cluster_issuer_venafi_username: <USERNAME>
+  cluster_issuer_venafi_password: <PASSWORD>
+
+Access Token
+************
+
+If you are using an access token to authenticate to Venafi, you can configure it
+with the following variable:
+
+.. code-block:: yaml
+
+  cluster_issuer_venafi_access_token: <ACCESS_TOKEN>
+
+Certificate fields
+~~~~~~~~~~~~~~~~~~
+
+If your Venafi zone is strict about the fields that are required or their
+values, you can use the `cert-manager supported annotations <https://cert-manager.io/docs/usage/ingress/#supported-annotations>`_
+to configure the certificate values.
+
+In order to apply these annotations to all ingresses managed by Atmosphere, you
+can use the ``ingress_global_annotations`` variable in your inventory which will
+apply the annotations to all ingresses.
+
+.. code-block:: yaml
+
+  ingress_global_annotations:
+    cert-manager.io/subject-organizations: VEXXHOST, Inc.
+    cert-manager.io/subject-organizationalunits: Cloud Infrastructure
+    cert-manager.io/subject-localities: Montreal
+    cert-manager.io/subject-provinces: Quebec
+    cert-manager.io/subject-countries: CA
+
+Using Pre-existing CA
+---------------------
+
+If you have an existing CA that you'd like to use with Atmosphere, you can
+configure it by including the certificate and private key:
+
+.. code-block:: yaml
+
+  cluster_issuer_type: ca
+  cluster_issuer_ca_certificate: |
+    -----BEGIN CERTIFICATE-----
+    MIIDBjCCAe4CCQDQ3Z0Z2Z0Z0jANBgkqhkiG9w0BAQsFADCBhTELMAkGA1UEBhMC
+    VVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28x
+    ...
+    -----END CERTIFICATE-----
+  cluster_issuer_ca_private_key: |
+    -----BEGIN RSA PRIVATE KEY-----
+    MIIEpAIBAAKCAQEAw3Z0Z2Z0Z0jANBgkqhkiG9w0BAQsFADCBhTELMAkGA1UEBhMC
+    VVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28x
+    ...
+    -----END RSA PRIVATE KEY-----
+
+.. note::
+
+   If your issuer is an intermediate certificate, you will need to ensure that
+   the ``certificate`` key includes the full chain in the correct order of issuer,
+   intermediate(s), then root.
+
+Self-signed Certificates
+------------------------
+
+If you are in an environment which does not have a trusted certificate authority
+and it does not have access to the internet to be able to use LetsEncrypt, you
+can use self-signed certificates by adding the following to your inventory:
+
+.. code-block:: yaml
+
+  cluster_issuer_type: self-signed
+
+.. warning::
+
+   Self-signed certificates are not recommended for production environments.
+   They are only recommended for development and testing environments.
diff --git a/doc/source/deploy/index.rst b/doc/source/deploy/index.rst
index ff9238f..c736b3e 100644
--- a/doc/source/deploy/index.rst
+++ b/doc/source/deploy/index.rst
@@ -15,6 +15,7 @@
 
    inventory
    csi
+   certificates
    cinder
    glance
    neutron
diff --git a/roles/cluster_issuer/README.md b/roles/cluster_issuer/README.md
index 68839d0..d53f45d 100644
--- a/roles/cluster_issuer/README.md
+++ b/roles/cluster_issuer/README.md
@@ -1,135 +1 @@
 # `cluster_issuer`
-
-Atmosphere simplifies all the management of your SSL certificates for all of
-your API endpoints by automatically issuing and renewing certificates for you.
-
-## ACME
-
-Atmosphere uses the [ACME](https://tools.ietf.org/html/rfc8555) protocol by
-default to request certificates from [LetsEncrypt](https://letsencrypt.org/).
-
-This is configured to work out of the box if your APIs are publicly accessible,
-you just need to configure an email address.
-
-```yaml
-cluster_issuer_acme_email: user@example.com
-```
-
-If you're running your own internal ACME server, you can configure Atmosphere to
-point towards it by setting the `cluster_issuer_acme_server` variable.
-
-```yaml
-cluster_issuer_acme_server: https://acme.example.com
-cluster_issuer_acme_email: user@example.com
-```
-
-### DNS-01 challenges
-
-Atmosphere uses the `HTTP-01` solver by default, which means that as long as
-your ACME server can reach your API, you don't need to do anything else.
-
-If your ACME server cannot reach your API, you will need to use the DNS-01
-challenges which require you to configure your DNS provider.
-
-#### RFC2136
-
-If you have DNS server that supports RFC2136, you can use it to solve the DNS
-challenges, you can use the following configuration:
-
-```yaml
-cluster_issuer_acme_email: user@example.com
-cluster_issuer_acme_solver: rfc2136
-cluster_issuer_acme_rfc2136_nameserver: <NAMESERVER>:<PORT>
-cluster_issuer_acme_rfc2136_tsig_algorithm: <ALGORITHM>
-cluster_issuer_acme_rfc2136_tsig_key_name: <KEY_NAME>
-cluster_issuer_acme_rfc2136_tsig_secret_key: <SECRET_KEY>
-```
-
-#### Route53
-
-If you are using Route53 to host the DNS for your domains, you can use the
-following configuration:
-
-```yaml
-cluster_issuer_acme_email: user@example.com
-cluster_issuer_acme_solver: route53
-cluster_issuer_acme_route53_region: <REGION>
-cluster_issuer_acme_route53_hosted_zone_id: <HOSTED_ZONE_ID>
-cluster_issuer_acme_route53_access_key_id: <AWS_ACCESS_KEY_ID>
-cluster_issuer_acme_route53_secret_access_key: <AWS_SECRET_ACCESS_KEY>
-```
-
-!!! note
-
-   You'll need to make sure that your AWS credentials have the correct
-   permissions to update the Route53 zone.
-
-#### Godaddy
-
-If you're using Godaddy for the DNS of your domain, you can use the following
-configuration which depends on
-`cert-manager-webhook-godaddy`[https://github.com/snowdrop/godaddy-webhook].
-
-```yaml
-cluster_issuer_acme_email: user@example.com
-cluster_issuer_acme_solver: godaddy
-cluster_issuer_acme_godaddy_api_key: <GODADDY_API_KEY>
-cluster_issuer_acme_godaddy_secret_key: <GODADDY_SECRET_KEY>
-```
-
-#### Infoblox
-
-If you're using Infoblox for the DNS of your domain, you can use the following
-configuration which depends on
-`cert-manager-webhook-infoblox-wapi`[https://github.com/luisico/cert-manager-webhook-infoblox-wapi].
-
-```yaml
-cluster_issuer_acme_email: user@example.com
-cluster_issuer_acme_solver: infoblox
-cluster_issuer_acme_infoblox_view: <VIEW>
-cluster_issuer_acme_infoblox_host: <HOST>
-cluster_issuer_acme_infoblox_username: <USERNAME>
-cluster_issuer_acme_infoblox_password: <PASSWORD>
-```
-
-## Using pre-existing CA
-
-If you have an existing CA that you'd like to use with Atmosphere, you can
-simply configure it by including the certificate and private key:
-
-```yaml
-cluster_issuer_type: ca
-cluster_issuer_ca_certificate: |
-  -----BEGIN CERTIFICATE-----
-  MIIDBjCCAe4CCQDQ3Z0Z2Z0Z0jANBgkqhkiG9w0BAQsFADCBhTELMAkGA1UEBhMC
-  VVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28x
-  ...
-  -----END CERTIFICATE-----
-cluster_issuer_ca_private_key: |
-  -----BEGIN RSA PRIVATE KEY-----
-  MIIEpAIBAAKCAQEAw3Z0Z2Z0Z0jANBgkqhkiG9w0BAQsFADCBhTELMAkGA1UEBhMC
-  VVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28x
-  ...
-  -----END RSA PRIVATE KEY-----
-```
-
-!!! note
-
-   If your issuer is an intermediate certificate, you will need to ensure that
-   they `certificate` key includes the full chain in the correct order of issuer,
-   intermediate(s) then root.
-
-## Self-signed certificates
-
-If you are in an environment which does not have a trusted certificate authority
-and it does not have access to the internet to be able to use LetsEncrypt, you
-can use self-signed certificates by adding the following to your inventory:
-
-```yaml
-cluster_issuer_type: self-signed
-```
-
-!!! warning
-
-   Self-signed certificates are not recommended for production environments,
-   they are only recommended for development and testing environments.
diff --git a/roles/cluster_issuer/defaults/main.yml b/roles/cluster_issuer/defaults/main.yml
index 15db6a4..28ff024 100644
--- a/roles/cluster_issuer/defaults/main.yml
+++ b/roles/cluster_issuer/defaults/main.yml
@@ -29,6 +29,14 @@
 cluster_issuer_acme_cloudflare_email: "{{ cluster_issuer_acme_email }}"
 #cluster_issuer_acme_cloudflare_api_token: <CLOUDFLARE_API_TOKEN>
 
+cluster_issuer_venafi_secret_name: cert-manager-venafi-credentials
+# cluster_issuer_venafi_access_token:
+# cluster_issuer_venafi_username:
+# cluster_issuer_venafi_password:
+# cluster_issuer_venafi_zone:
+# cluster_issuer_venafi_tpp_url:
+# cluster_issuer_venafi_tpp_ca_bundle:
+
 cluster_issuer_acme_rfc2136_secret_name: cert-manager-issuer-tsig-secret-key
 # cluster_issuer_acme_rfc2136_nameserver: <NAMESERVER>:<PORT>
 # cluster_issuer_acme_rfc2136_tsig_algorithm: <ALGORITHM>
diff --git a/roles/cluster_issuer/tasks/type/venafi/main.yml b/roles/cluster_issuer/tasks/type/venafi/main.yml
new file mode 100644
index 0000000..006012f
--- /dev/null
+++ b/roles/cluster_issuer/tasks/type/venafi/main.yml
@@ -0,0 +1,63 @@
+# Copyright (c) 2024 VEXXHOST, Inc.
+#
+# Licensed under the Apache License, Version 2.0 (the "License"); you may
+# not use this file except in compliance with the License. You may obtain
+# a copy of the License at
+#
+#      http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+# License for the specific language governing permissions and limitations
+# under the License.
+
+- name: Create secret (username/password)
+  when:
+    - cluster_issuer_venafi_username is defined
+    - cluster_issuer_venafi_password is defined
+    - cluster_issuer_venafi_access_token is not defined
+  kubernetes.core.k8s:
+    state: present
+    definition:
+      - apiVersion: v1
+        kind: Secret
+        metadata:
+          name: "{{ cluster_issuer_venafi_secret_name }}"
+          namespace: cert-manager
+        stringData:
+          username: "{{ cluster_issuer_venafi_username }}"
+          password: "{{ cluster_issuer_venafi_password }}"
+
+- name: Create secret (access token)
+  when:
+    - cluster_issuer_venafi_username is not defined
+    - cluster_issuer_venafi_password is not defined
+    - cluster_issuer_venafi_access_token is defined
+  kubernetes.core.k8s:
+    state: present
+    definition:
+      - apiVersion: v1
+        kind: Secret
+        metadata:
+          name: "{{ cluster_issuer_venafi_secret_name }}"
+          namespace: cert-manager
+        stringData:
+          access-token: "{{ cluster_issuer_venafi_access_token }}"
+
+- name: Create ClusterIssuer
+  kubernetes.core.k8s:
+    state: present
+    definition:
+      apiVersion: cert-manager.io/v1
+      kind: ClusterIssuer
+      metadata:
+        name: "{{ cluster_issuer_name }}"
+      spec:
+        venafi:
+          zone: "{{ cluster_issuer_venafi_zone }}"
+          tpp:
+            url: "{{ cluster_issuer_venafi_tpp_url }}"
+            caBundle: "{{ cluster_issuer_venafi_tpp_ca_bundle }}"
+            credentialsRef:
+              name: "{{ cluster_issuer_venafi_secret_name }}"
diff --git a/roles/defaults/vars/main.yml b/roles/defaults/vars/main.yml
index 6d60ce3..c5afef3 100644
--- a/roles/defaults/vars/main.yml
+++ b/roles/defaults/vars/main.yml
@@ -21,10 +21,10 @@
   bootstrap: "registry.atmosphere.dev/library/heat:{{ atmosphere_release }}"
   ceph_config_helper: "registry.atmosphere.dev/library/libvirtd:{{ atmosphere_release }}"
   ceph: quay.io/ceph/ceph:v18.2.1
-  cert_manager_cainjector: quay.io/jetstack/cert-manager-cainjector:v1.7.1
-  cert_manager_cli: quay.io/jetstack/cert-manager-ctl:v1.7.1
-  cert_manager_controller: quay.io/jetstack/cert-manager-controller:v1.7.1
-  cert_manager_webhook: quay.io/jetstack/cert-manager-webhook:v1.7.1
+  cert_manager_cainjector: quay.io/jetstack/cert-manager-cainjector:v1.12.10
+  cert_manager_cli: quay.io/jetstack/cert-manager-ctl:v1.12.10
+  cert_manager_controller: quay.io/jetstack/cert-manager-controller:v1.12.10
+  cert_manager_webhook: quay.io/jetstack/cert-manager-webhook:v1.12.10
   cilium_node: quay.io/cilium/cilium:v1.14.8
   cilium_operator: quay.io/cilium/operator-generic:v1.14.8
   cinder_api: "registry.atmosphere.dev/library/cinder:{{ atmosphere_release }}"
diff --git a/roles/ingress/defaults/main.yml b/roles/ingress/defaults/main.yml
index bbb881a..c224e68 100644
--- a/roles/ingress/defaults/main.yml
+++ b/roles/ingress/defaults/main.yml
@@ -1,5 +1,18 @@
-# List of annotations to apply to the Ingress
-ingress_annotations: {}
+# Copyright (c) 2024 VEXXHOST, Inc.
+#
+# Licensed under the Apache License, Version 2.0 (the "License"); you may
+# not use this file except in compliance with the License. You may obtain
+# a copy of the License at
+#
+#      http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+# License for the specific language governing permissions and limitations
+# under the License.
+
+
 
 ingress_class_name: "{{ atmosphere_ingress_class_name }}"
 
@@ -14,3 +27,16 @@
 # ingress_service_port: number
 
 # ingress_secret_name: string
+
+# List of annotations to apply to the Ingress
+#
+# NOTE(mnaser): These are typically used by the role that calls
+#               the ingress role to pass annotations to the
+#               Ingress resource.  You should use role-specific
+#               variable to pass annotations or use the
+#               ingress_global_annotations variable to apply
+#               annotations to all Ingress resources.
+ingress_annotations: {}
+
+# List of annotations to apply to all Ingress resources
+ingress_global_annotations: {}
diff --git a/roles/ingress/templates/ingress.yml.j2 b/roles/ingress/templates/ingress.yml.j2
index 0e48273..cdc4791 100644
--- a/roles/ingress/templates/ingress.yml.j2
+++ b/roles/ingress/templates/ingress.yml.j2
@@ -3,10 +3,9 @@
 metadata:
   name: {{ ingress_name }}
   namespace: {{ ingress_namespace | default('default') }}
-{% if ingress_annotations %}
   annotations:
-    {{ ingress_annotations | to_nice_yaml | indent(4) }}
-{% endif %}
+    cert-manager.io/common-name: {{ ingress_host }}
+    {{ ingress_annotations | combine(ingress_global_annotations, recursive=True) | to_nice_yaml | indent(4) }}
 spec:
   ingressClassName: {{ ingress_class_name }}
   rules:
diff --git a/roles/openstack_helm_ingress/README.md b/roles/openstack_helm_ingress/README.md
index 9b245af..38a9547 100644
--- a/roles/openstack_helm_ingress/README.md
+++ b/roles/openstack_helm_ingress/README.md
@@ -1,39 +1 @@
 # `openstack_helm_ingress`
-
-## Using wildcard certificates
-
-If you have an existing wildcard certificate to use for all your endpoints
-with Atmosphere, you can simply configure it as follows;
-
-1. Create a Kubernetes TLS secret using your wildcard certificate, you can refer
-   to the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets)
-   for more details.
-
-   ```shell
-   kubectl -n openstack create secret tls wildcard-certs --key=/path/to/tls.key --cert=/path/to/tls.crt
-   ```
-
-   > **Note**
-   >
-   > If you have a certificate that needs to be combined with an intermediate
-   > certificate, you can combine them all to a single file with the certificate
-   > first, followed by the intermediate certificate, followed by the root.
-
-2. Update the `openstack_helm_ingress_secret_name` to point towards the name
-   of the secret you created in step 1.
-
-   ```yaml
-   openstack_helm_ingress_secret_name: wildcard-certs
-   ```
-
-3. Set cluster_issuer_type to none, this is required for other roles
-   like for example Horizon.
-
-   ```yaml
-   cluster_issuer_type: none
-   ```
-
-> **Note**
->
-> If you make this change after a deployment, you will need to re-run all of the
-> playbooks in order to update all the `Ingress` resources.