math-nao / certs Goto Github PK

View Code? Open in Web Editor NEW

132.0 132.0 33.0 171 KB

A Let's Encrypt certificates manager for Kubernetes

License: Apache License 2.0

Dockerfile 0.70% Shell 92.73% HTML 0.99% Mustache 5.59%

kubernetes letsencrypt

certs's People

Stargazers

Watchers

certs's Issues

Create new release

Hey,

Thanks again for creating this!

I'm using https://math-nao.github.io/certs/charts/index.yaml to install the chart, please could you create a new release so that I can continue using that source

Thanks
Tom

Renewal updates certificate secret, but not config secret

Renewal appears to have updated the certificate secret ([name]-tls), but not the config secret ([name]-tls-conf). This causes each run to think the certificate is expiring and attempt renewal. This pretty quickly burns through the 5 identical certificate rate limit for letsencrypt.

I'm still trying to work out what happened exactly, but by the time I found this, the logs for the successful renewal were gone and my only logs are the rate limited logs

Howto use wildcard certs in all namespaces with auto renewal ?

With Certs i can use acme.sh for a lot of dns providers which are not being coverd with cert-manager, what is really great.
I did specify the env value for my provider in values.yaml, and was able to get for a single host an valid cert with an ingress like you describe at your site.

I would like to know how can i setup a wildcard domain cert for use in all namespaces ?

What i would like to achieve is this:

Get a wildcard cert like this:
acme.sh --issue --dns dns_doapi -d kube.example.com -d *.kube.example.com -d *.gitlab.kube.example.com -d *.ws.gitpod.kube.example.com -d *.pipe.kube.example.com
Import this cert as tls wildcard-domain-tls (can be done with kubectl)
Distribute it to all namespaces as wildcard-domain-tls
with a renewal Job which renews the cert and updates the tls in every namespace

Or is this all already done by cert ?

UPDATE: I did generate a wildcard certifcate through configuring an ingress with multiple hosts, and it is updated in the namespace i created it.. So the only thing left is to copy the secret across all namespaces.

copy from one to other namespace:
kubectl get secrets wildcard-domain-tls --namespace=<old-namespace> -o yaml | sed 's/namespace: <old-namespace>/namespace: <new-namespace>/' | kubectl apply -f -

Still need a job for this on reneal or change you crontab job..

(Wildcard certs) Ingress TLS secrets are not updated because both cert hashes are empty strings

Greetings,

I've deployed this to my minikube cluster running k8s >= 1.16 and using helm3. So far the TLS cert and private key has not been attached to my nginx ingress controller. After digging into this for most of the day I realized it's because the shell script is not saving the certificate and private keys to a k8s TLS secret.

Important note, details and logs in this issue are from the first pod that ran immediately after helm deployment..

My SSL cert is for a wildcard domain name and I'm beginning to wonder if the asterisk in the domain name is causing issues due to shell file system path expansion. Since this is the first time the cert pod ran I'd expect the "current cert hash" to be an empty string/null and the "new cert hash" to contain a hash of the newly issued cert, however they are both empty strings/null.

Here's where the hash conditional check evaluates as false because both hash values are empty string, therefore bypassing functions that save the certs to k8s TLS secrets.

https://github.com/math-nao/certs/blob/master/scripts/certs.sh#L282

I also noticed the "domain folder" variables are empty strings, shouldn't they be paths? Perhaps more validation needs to be added to ensure these variables are not empty strings and check if they exist?

Here is what I think to be the most important logs.

Info: Generate certs for  dns: dns_cloudns,  is_staging: true,  is_debug: true,  args: ,  cmd to use: acme.sh --issue --ca-file '/root/certs/ca.crt' --cert-file '/root/certs/tls.crt' --fullchain-file '/root/certs/fullchain.crt' --key-file '/root/certs/tls.key' -d '*.dev.mydomain.com' --staging --dns 'dns_cloudns',  name: ingress-tls-secrets,  namespace: myappnamespace,  domains: 31021.dev.mydomain.com 32010.dev.mydomain.com
Debug: main domain: 31021.dev.mydomain.com
Debug: domain folder: 
Debug: current cert hash: 
Debug: Running cmd: acme.sh --issue --ca-file '/root/certs/ca.crt' --cert-file '/root/certs/tls.crt' --fullchain-file '/root/certs/fullchain.crt' --key-file '/root/certs/tls.key' -d '*.dev.mydomain.com' --staging --dns 'dns_cloudns'
[Wed Feb 26 07:48:29 UTC 2020] Your cert is in  /acme.sh/*.dev.mydomain.com/*.dev.mydomain.com.cer 
[Wed Feb 26 07:48:29 UTC 2020] Your cert key is in  /acme.sh/*.dev.mydomain.com/*.dev.mydomain.com.key 
[Wed Feb 26 07:48:29 UTC 2020] The intermediate CA cert is in  /acme.sh/*.dev.mydomain.com/ca.cer 
[Wed Feb 26 07:48:29 UTC 2020] And the full chain certs is there:  /acme.sh/*.dev.mydomain.com/fullchain.cer 
[Wed Feb 26 07:48:29 UTC 2020] Installing cert to:/root/certs/tls.crt
[Wed Feb 26 07:48:29 UTC 2020] Installing CA to:/root/certs/ca.crt
[Wed Feb 26 07:48:29 UTC 2020] Installing key to:/root/certs/tls.key
[Wed Feb 26 07:48:29 UTC 2020] Installing full chain to:/root/certs/fullchain.crt
Info: acme.sh return code: 0
Debug: domain folder: 
Debug: new cert hash: 
Info: No certificate change, nothing to do

Full log output below with sensitive information redacted.

wait few seconds in case ingress rule is deployed at the same as it is in demo
Info: Initialize environment...
Info: No cmd args found
Info: Generate certs for  dns: dns_cloudns,  is_staging: true,  is_debug: true,  args: ,  cmd to use: acme.sh --issue --ca-file '/root/certs/ca.crt' --cert-file '/root/certs/tls.crt' --fullchain-file '/root/certs/fullchain.crt' --key-file '/root/certs/tls.key' -d '*.dev.mydomain.com' --staging --dns 'dns_cloudns',  name: helm-node-port-ingress-tls-secrets,  namespace: myappnamespace,  domains: 31021.dev.mydomain.com 32010.dev.mydomain.com
Info: Loading conf from secret...
Debug: Status code: 404
Info: Invalid status code found: 404, configuration not loaded
Debug: main domain: 31021.dev.mydomain.com
Debug: domain folder: 
Debug: current cert hash: 
Debug: Running cmd: acme.sh --issue --ca-file '/root/certs/ca.crt' --cert-file '/root/certs/tls.crt' --fullchain-file '/root/certs/fullchain.crt' --key-file '/root/certs/tls.key' -d '*.dev.mydomain.com' --staging --dns 'dns_cloudns'
[Wed Feb 26 07:47:34 UTC 2020] Using stage ACME_DIRECTORY: https://acme-staging-v02.api.letsencrypt.org/directory
[Wed Feb 26 07:47:35 UTC 2020] Create account key ok.
[Wed Feb 26 07:47:35 UTC 2020] Registering account
[Wed Feb 26 07:47:35 UTC 2020] Registered
[Wed Feb 26 07:47:35 UTC 2020] ACCOUNT_THUMBPRINT='cuFlQk1Ew3d853EOrVd'
[Wed Feb 26 07:47:35 UTC 2020] Creating domain key
[Wed Feb 26 07:47:36 UTC 2020] The domain key is here: /acme.sh/*.dev.mydomain.com/*.dev.mydomain.com.key
[Wed Feb 26 07:47:36 UTC 2020] Single domain='*.dev.mydomain.com'
[Wed Feb 26 07:47:36 UTC 2020] Getting domain auth token for each domain
[Wed Feb 26 07:47:36 UTC 2020] Getting webroot for domain='*.dev.mydomain.com'
[Wed Feb 26 07:47:36 UTC 2020] Adding txt value: 02mZ8mkugqZRwQDX8b-QHtJN54 for domain:  _acme-challenge.dev.mydomain.com
[Wed Feb 26 07:47:36 UTC 2020] Using cloudns
[Wed Feb 26 07:47:38 UTC 2020] Adding the TXT record for _acme-challenge.dev.mydomain.com
[Wed Feb 26 07:47:39 UTC 2020] Added.
[Wed Feb 26 07:47:39 UTC 2020] The txt record is added: Success.
[Wed Feb 26 07:47:39 UTC 2020] Let's check each dns records now. Sleep 20 seconds first.
[Wed Feb 26 07:47:59 UTC 2020] Checking dev.mydomain.com for _acme-challenge.dev.mydomain.com
[Wed Feb 26 07:48:00 UTC 2020] Not valid yet, let's wait 10 seconds and check next one.
[Wed Feb 26 07:48:10 UTC 2020] Let's wait 10 seconds and check again.
[Wed Feb 26 07:48:20 UTC 2020] Checking dev.mydomain.com for _acme-challenge.dev.mydomain.com
[Wed Feb 26 07:48:21 UTC 2020] Domain dev.mydomain.com '_acme-challenge.dev.mydomain.com' success.
[Wed Feb 26 07:48:21 UTC 2020] All success, let's return
[Wed Feb 26 07:48:21 UTC 2020] Verifying: *.dev.mydomain.com
[Wed Feb 26 07:48:24 UTC 2020] Success
[Wed Feb 26 07:48:24 UTC 2020] Removing DNS records.
[Wed Feb 26 07:48:24 UTC 2020] Removing txt: 02mZ8mkugqZRwQDX8b-QHtJN54 for domain: _acme-challenge.dev.mydomain.com
[Wed Feb 26 07:48:24 UTC 2020] Using cloudns
[Wed Feb 26 07:48:27 UTC 2020] Deleting the TXT record for _acme-challenge.dev.mydomain.com
[Wed Feb 26 07:48:27 UTC 2020] Deleted.
[Wed Feb 26 07:48:27 UTC 2020] Removed: Success
[Wed Feb 26 07:48:27 UTC 2020] Verify finished, start to sign.
[Wed Feb 26 07:48:27 UTC 2020] Lets finalize the order, Le_OrderFinalize: https://acme-staging-v02.api.letsencrypt.org/acme/finalize/12580894/76749265
[Wed Feb 26 07:48:28 UTC 2020] Download cert, Le_LinkCert: https://acme-staging-v02.api.letsencrypt.org/acme/cert/faabbedb70adc462c37f2
[Wed Feb 26 07:48:29 UTC 2020] Cert success.
-----BEGIN CERTIFICATE-----
MIIFWDCCBECgAwIBAgITAPqrvttwrcRiw38vyXC2qkU90zANBgkqhkiG9w0BAQsF
ADAiMSAwHgYDVQQDDBdGYWtlIExFIEludGVybWVk
...removed for privacy...
-----END CERTIFICATE-----
[Wed Feb 26 07:48:29 UTC 2020] Your cert is in  /acme.sh/*.dev.mydomain.com/*.dev.mydomain.com.cer 
[Wed Feb 26 07:48:29 UTC 2020] Your cert key is in  /acme.sh/*.dev.mydomain.com/*.dev.mydomain.com.key 
[Wed Feb 26 07:48:29 UTC 2020] The intermediate CA cert is in  /acme.sh/*.dev.mydomain.com/ca.cer 
[Wed Feb 26 07:48:29 UTC 2020] And the full chain certs is there:  /acme.sh/*.dev.mydomain.com/fullchain.cer 
[Wed Feb 26 07:48:29 UTC 2020] Installing cert to:/root/certs/tls.crt
[Wed Feb 26 07:48:29 UTC 2020] Installing CA to:/root/certs/ca.crt
[Wed Feb 26 07:48:29 UTC 2020] Installing key to:/root/certs/tls.key
[Wed Feb 26 07:48:29 UTC 2020] Installing full chain to:/root/certs/fullchain.crt
Info: acme.sh return code: 0
Debug: domain folder: 
Debug: new cert hash: 
Info: No certificate change, nothing to do

Values schema mismatch with defaults

Trying to deploy with the latest updates. Getting this error from helm when using the default values:

Error: UPGRADE FAILED: values don't meet the specifications of the schema(s) in the following chart(s):
certs:
- successfulJobsHistoryLimit: Invalid type. Expected: string, given: integer
- failedJobsHistoryLimit: Invalid type. Expected: string, given: integer
- backoffLimit: Invalid type. Expected: string, given: integer
- debug: Invalid type. Expected: boolean, given: string
- activeDeadlineSeconds: Invalid type. Expected: string, given: integer
- ttlSecondsAfterFinished: Invalid type. Expected: string, given: integer

[Question] Can this be adjusted to support istio gateways?

Relatively new to kuberenetes and I am using istio with gateways. Having issues getting cert-manager to work with GoDaddy and found this repo. But I am not sure if the annotations work only for ingress or they can also be added to gateways as well.

Document the need to suffix ing secret with -conf

Firstly, thank you for making this cert :).

What I think is the problem

It's not clear that the secretName used in the ingress needs to have the suffix "-conf".

        local SECRETNAME=$(echo ${input} | jq -rc '.secretName')

https://github.com/math-nao/certs/blob/master/scripts/certs.sh#L210

I had my ingress setup with a secretName called "tls".

Solution

Make a note in the README it needs the suffix.

Reference

Please update your account with an email address first

---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: kubernetes-dashboard-ingress
  namespace: kubernetes-dashboard
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
    acme.kubernetes.io/enable: "true"
    acme.kubernetes.io/dns: "dns_gd"
    acme.kubernetes.io/cmd-to-use: "acme.sh --register-account -m [email protected]"

wait few seconds in case ingress rule is deployed at the same as it is in demo
Before script
Info: Initialize environment...
Info: No cmd to use found
Info: No cmd args found
Info: Generate certs for dns: dns_gd, is_staging: false, is_debug: false, args: , cmd to use: , name: ca-kubedash-example-cert-secret, namespace: kubernetes-dashboard, domains: kubedash.labs.example.com
Info: Loading conf from secret...
Info: Invalid status code found: 404, configuration not loaded
[Tue Aug 17 09:22:17 UTC 2021] Sleep 10 and retry.
[Tue Aug 17 09:22:28 UTC 2021] Using CA: https://acme.zerossl.com/v2/DV90
[Tue Aug 17 09:22:28 UTC 2021] Create account key ok.
[Tue Aug 17 09:22:28 UTC 2021] No EAB credentials found for ZeroSSL, let's get one
[Tue Aug 17 09:22:28 UTC 2021] acme.sh is using ZeroSSL as default CA now.
[Tue Aug 17 09:22:28 UTC 2021] Please update your account with an email address first.
[Tue Aug 17 09:22:28 UTC 2021] acme.sh --register-account -m [email protected]
[Tue Aug 17 09:22:28 UTC 2021] See: https://github.com/acmesh-official/acme.sh/wiki/ZeroSSL.com-CA
[Tue Aug 17 09:22:28 UTC 2021] Please add '--debug' or '--log' to check more details.
[Tue Aug 17 09:22:28 UTC 2021] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh
Info: acme.sh return code: 1
Info: An acme.sh error occurred

Errors with K3S cluster

Kubernetes API version: v1.17.2+k3s1
OS: Ubuntu Server 18.04.4 LTS
helm: 3.1.1

helm install --namespace app --values values.yaml certs certs/certs

Gives the following error:
Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [ValidationError(Job.spec.template.spec): unknown field "backoffLimit" in io.k8s.api.core.v1.PodSpec, ValidationError(Job.spec.template.spec): unknown field "concurrencyPolicy" in io.k8s.api.core.v1.PodSpec, ValidationError(Job.spec.template.spec): unknown field "ttlSecondsAfterFinished" in io.k8s.api.core.v1.PodSpec]

Certs are not saved

2019-09-07T02:23:31.400005325Z wait few seconds in case ingress rule is deployed at the same as it is in demo
2019-09-07T02:24:01.404948717Z Info: Initialize environment...
2019-09-07T02:24:01.601586982Z Info: No cmd to use found
2019-09-07T02:24:01.649911669Z Info: No cmd args found
2019-09-07T02:24:01.89497221Z Info: Loading conf from secret...
2019-09-07T02:24:01.927295396Z Info: Adding conf
2019-09-07T02:24:03.211477609Z [Sat Sep  7 02:24:03 UTC 2019] Domains not changed.
2019-09-07T02:24:03.217582975Z [Sat Sep  7 02:24:03 UTC 2019] Skip, Next renewal time is: Fri Nov  1 16:42:08 UTC 2019
2019-09-07T02:24:03.219283893Z [Sat Sep  7 02:24:03 UTC 2019] Add '--force' to force to renew.
2019-09-07T02:24:03.219655926Z acme.sh return code: 2
2019-09-07T02:24:03.228111638Z Info: No certificate change, nothing to do
2019-09-07T02:24:03.332223492Z Info: No cmd to use found
2019-09-07T02:24:03.384506315Z Info: No cmd args found
2019-09-07T02:24:03.628450167Z Info: Loading conf from secret...
2019-09-07T02:24:03.662897383Z Info: Invalid status code found: 404, configuration not loaded
2019-09-07T02:24:05.085247784Z [Sat Sep  7 02:24:05 UTC 2019] Create account key ok.
2019-09-07T02:24:05.118810287Z [Sat Sep  7 02:24:05 UTC 2019] Registering account
2019-09-07T02:24:08.224343066Z [Sat Sep  7 02:24:08 UTC 2019] Registered
2019-09-07T02:24:08.253496912Z [Sat Sep  7 02:24:08 UTC 2019] ACCOUNT_THUMBPRINT=''
2019-09-07T02:24:08.257990397Z [Sat Sep  7 02:24:08 UTC 2019] Creating domain key
2019-09-07T02:24:08.406181999Z [Sat Sep  7 02:24:08 UTC 2019] The domain key is here: /acme.sh/domain.com/domain.com.key
2019-09-07T02:24:08.40660184Z [Sat Sep  7 02:24:08 UTC 2019] Single domain='domain.com'
2019-09-07T02:24:08.430217919Z [Sat Sep  7 02:24:08 UTC 2019] Getting domain auth token for each domain
2019-09-07T02:24:11.050196284Z [Sat Sep  7 02:24:11 UTC 2019] Getting webroot for domain='domain.com'
2019-09-07T02:24:11.096982909Z [Sat Sep  7 02:24:11 UTC 2019] Adding txt value: ... for domain:  _acme-challenge.domain.com
2019-09-07T02:24:14.167799451Z [Sat Sep  7 02:24:14 UTC 2019] The txt record is added: Success.
2019-09-07T02:24:14.169522519Z [Sat Sep  7 02:24:14 UTC 2019] Let's check each dns records now. Sleep 20 seconds first.
2019-09-07T02:24:34.196268015Z [Sat Sep  7 02:24:34 UTC 2019] Checking domain.com for _acme-challenge.domain.com
2019-09-07T02:24:38.025450474Z [Sat Sep  7 02:24:38 UTC 2019] Domain domain.com '_acme-challenge.domain.com' success.
2019-09-07T02:24:38.026883308Z [Sat Sep  7 02:24:38 UTC 2019] All success, let's return
2019-09-07T02:24:38.037049668Z [Sat Sep  7 02:24:38 UTC 2019] Verifying: domain.com
2019-09-07T02:24:42.35930862Z [Sat Sep  7 02:24:42 UTC 2019] Success
2019-09-07T02:24:42.360829612Z [Sat Sep  7 02:24:42 UTC 2019] Removing DNS records.
2019-09-07T02:24:42.376119396Z [Sat Sep  7 02:24:42 UTC 2019] Removing txt: ... for domain: _acme-challenge.domain.com
2019-09-07T02:24:46.137665495Z [Sat Sep  7 02:24:46 UTC 2019] Removed: Success
2019-09-07T02:24:46.143206751Z [Sat Sep  7 02:24:46 UTC 2019] Verify finished, start to sign.
2019-09-07T02:24:46.150803379Z [Sat Sep  7 02:24:46 UTC 2019] Lets finalize the order, Le_OrderFinalize: https://acme-v02.api.letsencrypt.org/acme/finalize/...
2019-09-07T02:24:49.374678203Z [Sat Sep  7 02:24:49 UTC 2019] Download cert, Le_LinkCert: https://acme-v02.api.letsencrypt.org/acme/cert/...
2019-09-07T02:24:50.657401035Z [Sat Sep  7 02:24:50 UTC 2019] Cert success.
2019-09-07T02:24:50.658681491Z -----BEGIN CERTIFICATE-----
2019-09-07T02:24:50.658848388Z -----END CERTIFICATE-----
2019-09-07T02:24:50.660652675Z [Sat Sep  7 02:24:50 UTC 2019] Your cert is in  /acme.sh/domain.com/dev.tail0r.com.cer 
2019-09-07T02:24:50.662449191Z [Sat Sep  7 02:24:50 UTC 2019] Your cert key is in  /acme.sh/domain.com/dev.tail0r.com.key 
2019-09-07T02:24:50.670371273Z [Sat Sep  7 02:24:50 UTC 2019] The intermediate CA cert is in  /acme.sh/domain.com/ca.cer 
2019-09-07T02:24:50.672009183Z [Sat Sep  7 02:24:50 UTC 2019] And the full chain certs is there:  /acme.sh/domain.com/fullchain.cer 
2019-09-07T02:24:50.718138421Z [Sat Sep  7 02:24:50 UTC 2019] Installing cert to:/root/certs/tls.crt
2019-09-07T02:24:50.7203467Z [Sat Sep  7 02:24:50 UTC 2019] Installing CA to:/root/certs/ca.crt
2019-09-07T02:24:50.722827963Z [Sat Sep  7 02:24:50 UTC 2019] Installing key to:/root/certs/tls.key
2019-09-07T02:24:50.72731135Z acme.sh return code: 0
2019-09-07T02:24:50.73476201Z Info: No certificate change, nothing to do

As you can see from the log, the cert of the second ingress is newly generated, but certs says "No certificate change, nothing to do" so the cert is not saved to kubernetes.

Does this support wildcard certificates ?

Cert is not issues

Version: 1.1.10
wait few seconds in case ingress rule is deployed at the same as it is in demo
Before script
Info: Initialize environment...
Info: No cmd args found
Info: Generate certs for dns: dns_gd, is_staging: false, is_debug: false, args: , cmd to use: acme.sh --register-account -m [email protected], name: ca-kubedash-rvsharma-cert-secret, namespace: kubernetes-dashboard, domains: kubedash.labs.rvsharma.com
Info: Loading conf from secret...
Info: Invalid status code found: 404, configuration not loaded
[Tue Aug 17 10:13:08 UTC 2021] Create account key ok.
[Tue Aug 17 10:13:08 UTC 2021] No EAB credentials found for ZeroSSL, let's get one
[Tue Aug 17 10:13:09 UTC 2021] Registering account: https://acme.zerossl.com/v2/DV90
[Tue Aug 17 10:13:13 UTC 2021] Registered
[Tue Aug 17 10:13:13 UTC 2021] ACCOUNT_THUMBPRINT='lwwxDxUNfq2WUUxKGnVNSPdGeCAsIx7okXGgGzLHLJlxk'
Info: acme.sh return code: 0
Info: No certificate change, nothing to do
Exiting...
After script

On every cron pod it's returning the same output, with any ingress.

Usage

Hi,
I am using Rancher, MetalLb and Traefik. I have 2 x traefik instances point to a folder where the certificates are, one folder for each since both are wildcard certificates but two depth so one it internal.mydomain.com and one is mydomain.com. How can i achieve that with this ?

/donnib

parse error: Unfinished string at EOF at line 2, column 0

According to doc, we can set acme.kubernetes.io/add-args to --keylength ec-256 and expect to get an ec-256 certificate. However, if I add this line, there will be an error:

2019-09-03T16:02:16.734148023Z wait few seconds in case ingress rule is deployed at the same as it is in demo
2019-09-03T16:02:46.766496425Z Info: Initialize environment...
2019-09-03T16:02:47.020351981Z Info: No cmd to use found
2019-09-03T16:02:47.072649822Z Info: No cmd args found
2019-09-03T16:02:47.341249161Z Info: Loading conf from secret...
2019-09-03T16:02:47.370302579Z Info: Adding conf
2019-09-03T16:02:50.741535773Z [Tue Sep  3 16:02:50 UTC 2019] Domains not changed.
2019-09-03T16:02:50.744926787Z [Tue Sep  3 16:02:50 UTC 2019] Skip, Next renewal time is: Fri Nov  1 16:42:08 UTC 2019
2019-09-03T16:02:50.746002542Z [Tue Sep  3 16:02:50 UTC 2019] Add '--force' to force to renew.
2019-09-03T16:02:50.746188391Z acme.sh return code: 2
2019-09-03T16:02:50.752648281Z Info: No certificate change, nothing to do
2019-09-03T16:02:50.803584239Z parse error: Unfinished string at EOF at line 2, column 0

If I remove this line, it will be fine.

403 in Job

Hi,

I'm having some issues that I hope you can help me solve.

I 2019-12-10T13:54:22.566587491Z wait few seconds in case ingress rule is deployed at the same as it is in demo
 
I 2019-12-10T13:54:52.569763971Z Info: Initialize environment...
 
I 2019-12-10T13:54:52.617841989Z Info: Invalid status code found: 403

I'm getting this error in the Kubernetes Job.

I'm using Domeneshop.no as my ISP. This is the yaml

spec:
  activeDeadlineSeconds: 600
  containers:
  - env:
    - name: ACME_MANAGE_ALL_NAMESPACES
      value: "true"
    - name: ACME_DEMO_ENABLED
      value: "false"
    - name: ACME_DEBUG
      value: "true"
    - name: DOMENESHOP_Token
      value: mytokenhere
    - name: DOMENESHOP_Secret
      value: mysecrethere
    image: mathnao/certs:1.1.3
    imagePullPolicy: Always
    name: certs
    resources: {}
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: certs-token-p4zj8
      readOnly: true

I'm fully able to generate the certificates manually with acme.sh from the repo https://github.com/Neilpang/acme.sh, and with the exact same tokens.

Support service ressource

For example, https://www.getambassador.io/ does not create ingress just a service. It would be great to support it.

K8S 1.22 support

The URI to the ingresses API is hard-coded to /apis/extensions/v1beta1 here: https://github.com/math-nao/certs/blob/master/scripts/certs.sh#L174

This is deprecated and removed in K8S 1.22. To continue to work with 1.22, it should be changed to /apis/networking.k8s.io/v1.

RBAC rules must also be updated such that the networking.k8s.io API group is accessible, rather than extensions.

I can submit a PR if you'd like, but I'm not sure exactly how you would wish to maintain backwards compatibility.

Thank you for the excellent repo.

is it currently working with Dynu?

Hello, the log gives an error code 6, which indicates that CURLE_COULDNT_RESOLVE_HOST (6)

[Sat Jun 24 19:23:50 UTC 2023] GET
[Sat Jun 24 19:23:50 UTC 2023] url='https://acme-staging-v02.api.letsencrypt.org/directory'
[Sat Jun 24 19:23:50 UTC 2023] timeout=
[Sat Jun 24 19:23:50 UTC 2023] _CURL='curl --silent --dump-header /acme.sh/http.header  -L  -g '
[Sat Jun 24 19:23:55 UTC 2023] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6
[Sat Jun 24 19:23:55 UTC 2023] ret='6'
[Sat Jun 24 19:23:55 UTC 2023] Can not init api for: https://acme-staging-v02.api.letsencrypt.org/directory.
[Sat Jun 24 19:23:55 UTC 2023] Sleep 10 and retry.

I would like to know if this repository is currently active and updated with Dynu..

Thank you !

Namespace error

Hi.

I came across this project and thought I would try it but came across a couple of issues that I see in the code. You have hardcoded the namespace to app in the following files:

certs/templates/rolebinding.yaml
certs/templates/serviceaccount.yaml
certs/templates/role.yaml

This results in error when trying to install the chart in another namespace. I thought I'd let you know.

Upon error code 2 from acme.sh, certs.sh does not correctly trap and destroys the TLS secrets

Reviewing https://github.com/math-nao/certs/blob/master/scripts/certs.sh ....

Line 311 is a return on when acme.sh with return code 2 (no update needed) is fired. This appears not to be honored as acme.sh returns an error code of 2 (no update required) and the add_certs_to_secret function is executed anyway. In a loop with multiple domains and multiple ingress definitions, this results in two issues:

If the cert is the first cert to be renewed, the secret is blown out with null values as the cat command finds no file
If a previous execution loop was successful, the previous loop's TLS files are leveraged for the wrong domain/loop because of a name collision in the hardcoded pem filenames.

Example of the first state:

Info: Loading conf from secret...
Info: Adding conf
[Wed Jul 29 12:00:37 UTC 2020] Domains not changed.
[Wed Jul 29 12:00:37 UTC 2020] Skip, Next renewal time is: Mon Sep 21 23:55:12 UTC 2020
[Wed Jul 29 12:00:37 UTC 2020] Add '--force' to force to renew.
Info: acme.sh return code: 2
Info: Certificate change, updating...
Info: Adding certs to secret...
cat: /root/certs/ca.crt: No such file or directory
cat: /root/certs/fullchain.crt: No such file or directory
cat: /root/certs/tls.key: No such file or directory
Info: Updating certs
Info: Certs sucessfully added
Info: Adding conf to secret...
Info: domain folder is not a directory
Info: No cmd args found

Inspecting the secret:

$ kubectl get secrets -n **** helm-****************-tls-secrets -o yaml
apiVersion: v1
data:
  ca.crt: ""
  tls.crt: ""
  tls.key: ""
kind: Secret
metadata:
  creationTimestamp: "2020-07-23T23:55:12Z"
  name: helm-****************-tls-secrets
  namespace: *****
  resourceVersion: "2*******3"
  selfLink: /api/v1/namespaces/*****/secrets/helm-****************-tls-secrets
  uid: 00000000-0000-0000-0000-000000000000
type: Opaque

In the second state... you can easily see this by inspecting the certificate after certs.sh runs acme.sh looping. Simply output the secret and push it into openssl and inspect the CN in the cert:

$ kubectl get secrets -n ***** helm-****************-tls-secrets -o 'go-template={{index .data "tls.crt"}}' | base64 -D | openssl x509 -noout -text

We've had this result in bad certificates (the default kubernetes ingress certificate because tls.crt and tls.key are null) and wrong certificates (domain 2 has domain 1's cert) in production environments... which is bad.

This also can lead to a situation where multiple runs to "jiggle the handle" to fix stuff hits the LetsEncrypt API restrictions. This is also bad when you cannot generate a cert for your production environment because acme.sh has reached out for a new cert 5 times in a week.

Job finishes succesfully on renewing certs but ssl are not used by https

Not sure how to help with this one.

I believe renew of certs used to work.
I have recently added more domains and I am wondering if that has caused trouble...

The certs job seems happy, but looped over enough letsencrypt has ratelimited me.

[Wed Jan 17 18:39:44 UTC 2024] Installing cert to: /root/certs/tls.crt
[Wed Jan 17 18:39:44 UTC 2024] Installing CA to: /root/certs/ca.crt
[Wed Jan 17 18:39:44 UTC 2024] Installing key to: /root/certs/tls.key
[Wed Jan 17 18:39:44 UTC 2024] Installing full chain to: /root/certs/fullchain.crt

The job seems happy, and says nothing needs renewing, but the secrets are not updated and the endpoint says the cert is out of date.

Looking into the secrets, it appears that there is more than one certificate in "tls.crt", "ca.crt".

Also when I decode the conf secrets, there are things like "rootroot" and it almost looks like there should have been some new lines.

Here is an example

acme.sh/www.learnalist.net_ecc/fullchain.cerXXX 0ustar  rootroot-----BEGIN CERTIFICATE-----

Also at the top of the conf

acme.sh/www.learnalist.net_ecc/www.learnalist.net.csr.confXXX 0ustar  rootroot[ req_distinguished_name ]

I lack detailed knowledge but I have a feeling rootroot maybe should have been "newline", as I suspect

[ req_distinguished_name ]

should be on its own line like other conf blocks.

Allow to configure a list of namespaces

Currently it is possible to use either a single namespace or all namespaces. I'd like to use certs to manage the certificates in a list of namespaces.

That would be useful since I'm using GKE Autopilot and when I try to configure to manage all namespaces I get an error (since the cluster is quite limited). If I could select a list of namespace I could just leave the restricted namespaces out of it.

Invalid status code found:

k logs -f certs-manually-20191109-103114-m84w9
wait few seconds in case ingress rule is deployed at the same as it is in demo
Info: Initialize environment...
Info: Invalid status code found: ```

values.yaml

schedule: "0 2,14 * * *"

env:

name: AWS_ACCESS_KEY_ID
value: redacted
name: AWS_SECRET_ACCESS_KEY
value: redacted

chart: schedule value does not work with some expressions

I've been testing certs in a test cluster and in general it works great. I want to react to ingress changes in a fast way, So I want the verification job to run as fast as possible since there is no reaction from ingress changes implemented.

Im not sure this is a general helm problem, but using the chart and setting the value below, the chart installation errors out with yaml parsing error:

schedule: "*/2 * * * *"

I need to change the value to the more verbose format below to the template to render:

schedule: "0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46,48,50,52,54,56,58 * * * *"

math-nao / certs Goto Github PK

certs's People

Stargazers

Watchers

Forkers

certs's Issues

What I think is the problem

Solution

Reference

Recommend Projects

Recommend Topics

Recommend Org

Jobs