getssl VS cert-manager

A 'competitor' to this would be GetSSL which is a pure-shell ACME client (plus OpenSSL and cURL) and can be executed on one host, but send verification tokens to remote systems (where you may not have cron access):

> Get certificates for remote servers - The tokens used to provide validation of domain ownership, and the certificates themselves can be automatically copied to remote servers (via ssh, sftp or ftp for tokens). The script doesn't need to run on the server itself. This can be useful if you don't have access to run such scripts on the server itself, as it's a shared server for example.

* https://github.com/srvrco/getssl

I first got by with self signed certificates, but with all the major browsers warning they'll stop supporting those eventually I finally bit the bullet last month and installed getssl to automatically update all my certificates once a month.

because I didn't want to install another package manager (snapd) on my Ubuntu 18.04 server I checked the ACME Client Implementations page and decided to try getssl, a nice little shell script that does everything I need and then some.

I just have a dedicated container that runs getssl everyday. Anything that has a web interface (Or anything that requires TLS) gets it's own conf file that gets added to the daily check. Each conf file tells getssl how to load the certificate for its particular service.

I have been using https://github.com/srvrco/getssl for years on my raspberry pi. It's a much simpler Bash script that doesn't break after every update.

i have a problem where after installing getssl (https://github.com/srvrco/getssl) to /root/.getssl i populated it's contents with bunch of SSL files using Dockerfile's COPY command. And now no matter what i do they keep reappearing.

> acme.sh

Another shell-based ACME client I like is dehyradted. But for sending certs to remote systems from one central area, perhaps the shell-based GetSSL:

> Obtain SSL certificates from the letsencrypt.org ACME server. Suitable for automating the process on remote servers.

* https://github.com/srvrco/getssl

In general, what you may want to do is configure Ansible/Puppet/etc, and have your ACME client drop the new cert in a particular area and have your configuration management system push things out from there.

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