cert-manager VS acme.sh

cert-manager

The second one is a combination of tools: External DNS, cert-manager, and NGINX ingress. Using these as a stack, you can quickly deploy an application, making it available through a DNS with a TLS without much effort via simple annotations. When I first discovered External DNS, I was amazed at its quality.

On top of its core components, SpinKube depends on cert-manager. cert-Manager is responsible for provisioning and managing TLS certificates that are used by the admission webhook system of the Spin Operator. Let’s install cert-manager and KWasm using the commands shown here:

terraform { required_providers { kubectl = { source = "gavinbunney/kubectl" version = "1.14.0" } } } # The reference to the current project or a AWS project data "google_client_config" "provider" {} # The reference to the current cluster or EKS data "google_container_cluster" "my_cluster" { name = var.cluster_name location = var.cluster_location } # We configure the kubectl provider to use those values for authenticating provider "kubectl" { host = data.google_container_cluster.my_cluster.endpoint token = data.google_client_config.provider.access_token cluster_ca_certificate = base64decode(data.google_container_cluster.my_cluster.master_auth[0].cluster_ca_certificate) } #Download the multiple manifests file. data "http" "cert_manager_crds" { url = "https://github.com/cert-manager/cert-manager/releases/download/v${var.cert_manager_version}/cert-manager.crds.yaml" } data "kubectl_file_documents" "cert_manager_crds" { content = data.http.cert_manager_crds.response_body lifecycle { precondition { condition = 200 == data.http.cert_manager_crds.status_code error_message = "Status code invalid" } } } # We use the for_each or else this kubectl_manifest will only import the first manifest in the file. resource "kubectl_manifest" "cert_manager_crds" { for_each = data.kubectl_file_documents.cert_manager_crds.manifests yaml_body = each.value }

SSL certificates thanks to Cloudflare and cert-manager

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/${CERT_MANAGER_VERSION}/cert-manager.crds.yaml

put the Sub-CA inside hashicorp vault to be used for automatic signing of services like https://cert-manager.io/ inside our k8s clusters.

install-cert-manager: desc: Install cert-manager deps: - init-cluster cmds: - kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/{{.CERT_MANAGER_VERSION}}/cert-manager.yaml - echo "Waiting for cert-manager to be ready" && sleep 25 status: - kubectl -n cert-manager get pods | grep Running | wc -l | grep -q 3

I've been pretty frustrated with how private CAs are supported. Your private root CA can be maliciously used to MITM every domain on the Internet, even though you intend to use it for only a couple domain names. Most people forget to set Name Constraints when they create these and many helper tools lack support [1][2]. Worse, browser support for Name Constraints has been slow [3] and support isn't well tracked [4]. Public CAs give you certificate transparency and you can subscribe to events to detect mis-issuance. Some hosted private CAs like AWS's offer logs [5], but DIY setups don't.

Even still, there are a lot of folks happily using private CAs, they aren't the target audience for this initial release.

[1] https://github.com/FiloSottile/mkcert/issues/302

[2] https://github.com/cert-manager/cert-manager/issues/3655

[3] https://alexsci.com/blog/name-non-constraint/

[4] https://github.com/Netflix/bettertls/issues/19

[5] https://docs.aws.amazon.com/privateca/latest/userguide/secur...

the Cert Manager

Next, we will install acme.sh, a command-line tool for managing SSL/TLS certificates. I prefer acme.sh over certbot, as it does not depend on the OS version. For more details about acme.sh, check its GitHub repo here.

A very relevant question. Acme.sh, a similar shell script ACME client, had a remote code execution problem last year.

https://github.com/acmesh-official/acme.sh/issues/4668

As a result, any certificates issued (or renewed) after Feb 8th will not work on older Android devices (< 7.1.1), unless the ACME client has been configure to request an alternate certificate chain. The "alternate chain" workaround will also stop working on June 6th.

I need to support these older Android devices so I am looking for alternatives. I have seen ZeroSSL mentioned a few times; it is also the default CA for acme.sh (the ACME client I am using nowadays) [2]. They have a number of paid plans but ACME certificates are free [3].

I'll be testing this over the next few days, but I would also like to ask if people here have experience with ZeroSSL (good or bad :-). Any feedback would be helpful.

[1]: https://letsencrypt.org/2023/07/10/cross-sign-expiration.html

[2]: https://github.com/acmesh-official/acme.sh

[3]: https://zerossl.com/documentation/acme/

Huh, the environment variable thing was specifically aimed at acme.sh which rather arbitrarily changed the config value from ACMEDNS_UPDATE_URL to ACMEDNS_BASE_URL, never acknowledged this in a changelog and then silently failed after an automatic upgrade as recommended by the default install:

https://github.com/acmesh-official/acme.sh/commit/2ce145f359...

It's also cleared out my .account.conf files when run on the suggested cron.

I've started using updown which also monitors my TLS certs simply because I no longer trust the process to work as documented.

It depends on your provider though. I can tell from experience that with OVH and their API, it's been easy to set up the automatic renewal via DNS verification. Apparently, the official client has support for the DNS API of 159 providers: https://github.com/acmesh-official/acme.sh/wiki/dnsapi

For the few people here that happen to run a self-hosted email server with acme.sh for TLS key/cert generation and Cloudflare for DNS management, I have made a tool that i personally use to get a perfect 100% score on Internet.nl's email test.

All of this is to say it's a decent amount of work to save the hassle of deploying certbot or acme.sh on the remote machines, pick your poison.

Here is a really solid guide for setting up the ACME DNS challenge with pretty much any DNS provider

People wonder why I like using the shell-based ACME client like dehydrated (or acme.sh):

* https://packages.debian.org/search?keywords=dehydrated

* https://github.com/acmesh-official/acme.sh

Versus the official client certbot:

* https://packages.debian.org/search?keywords=python3-certbot

A kludgy as very long shell scripts are (thought to be), I have a better chance of being able to go through all the code and understand it than a dozen(+) Python libraries.

So today I figured out how to install acme.sh to my hosted server space for my websites, and used acme to issue an SSL certificate and install it for a domain. It uses LetsEncrypt, and ZeroSSL for the default Certificate Authority (CA). Then I notice that ZeroSSL only allows a free 90 day certificate, and only 3 of those before you have to pay. Is there any way to generate actual free SSL certificates that do not expire for a year or more and that can be renewed free? I have heard that most hosting plans now provide free SSL certs, so is my hosting company just providing cheap hosting but making money on the backend by charging for SSL certs?