bcdevops / certbot Goto Github PK

There's no need to target a specific mirror in https://github.com/BCDevOps/certbot/blob/master/docker/Dockerfile#L23, is there? https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm may be a more reliable result.

The certbot cron job generates a temporary route and service for the */.well-known/acme-challenge/ url. However it does not create a corresponding Network Policy allowing ingress through that route to the pod. In environments that do not define permissive ingress policies this results in the following error:

Requesting a certificate for email-verification-dev.vonx.io
Certbot failed to authenticate some domains (authenticator: standalone). The Certificate Authority reported these problems:
Domain: <your-domain>
Type: unauthorized
Detail: 142.34.194.118: Invalid response from http://<your-domain>/.well-known/acme-challenge/Ae4zCggGtBv8Q3bvJqeFIP7B4PIe3I9PCieJSi-rJVk: 503
Hint: The Certificate Authority failed to download the challenge files from the temporary standalone webserver started by Certbot on port 8080. Ensure that the listed domains point to this machine and that it can accept inbound connections from the internet.

In addition to the temporary route and service, a temporary network policy should also be created to allow ingress to the certbot pod. The service, route, and np should be created and cleaned up as a matching set, as is done now with the route and service.

As a workaround the following Network Policy can be added to the namespace in which the certbot jobs are running:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: certbot-allow-ingress
  labels:
    app: certbot
    name: certbot-allow-ingress
    role: certbot
spec:
  podSelector:
    matchLabels:
      app: certbot
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              network.openshift.io/policy-group: ingress
  policyTypes:
    - Ingress

Hello, I seem to not have permission to view the URL (https://apps.nrs.gov.bc.ca/int/jira/servicedesk/customer/portal/1/SD-26581). Is it possible to type it out on the page?

oc get route -l certbot-managed=true -o json | jq '.items[].spec.host' -r | sort -f | uniq -iu > /tmp/certbot-hosts.txt

Here if you have multiple routes with different paths but the same domain causes the uniq -iu command to return nothing. Tested on Openshift 4.x and Ubuntu 20.04 WSL.

Workaround: Label one route, run the certbot routine, and manually copy the certs into the other route yamls.

Entrust now supports ACME protocol. This ticket is for investigating the feasibility of using Entrust certificates.

Reference:

• https://www.entrustdatacard.com/knowledgebase/how-to-use-acme-to-install-ssl-tls-certificates-in-entrust-certificate-services-apache

When requesting an Entrust certificate, the following warning is printed

Certbot is configured to use an ACMEv1 server (https://www.entrust.net/acme/api/v1/directory/<ministry id here>). ACMEv1 support is deprecated and will soon be removed. See https://community.letsencrypt.org/t/143839 for more information.

ACMEv1 was deprecated by Let's Encrypt, but I'm unsure whether support for other servers is deprecated by Certbot itself. A careful look at the Certbot changelogs will be needed when upgrading it in the future.

right now, all routes gets lumped into 1 certificate request. We may need a way of splitting into multiple requests

We have certbot deployment imbedded into our pipeline so we end up building the image quite often. Recently, our cert renewal pod reported the error /usr/local/bin/oc-deploy-certs.sh: line 131: certbot: command not found and after some investigation found that in the build process we have No package certbot-1.3.0-1.el7 available error. I will try updating the Certbot version and do a PR for this.

Hi! The services that are being created have no pods attached to them.

We use certbot to request/renew a certifcate for getok.nrs.gov.bc.ca
We only use this non-www route but certbot makes requests for both www and non-www domains.
The non-www request was approved, but the www is declined by Entrust (with reason: 'Duplicate request with www. prefix. This is included in a standard license.')

However, the certbot seems to need both approved. Can anyone confirm if that is true?
The log on the certbot container looks like this:

Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator standalone, Installer None
Renewing an existing certificate for getok.nrs.gov.bc.ca and www.getok.nrs.gov.bc.ca
Performing the following challenges:
http-01 challenge for www.getok.nrs.gov.bc.ca
Waiting for verification...
Cleaning up challenges
Attempting to renew cert (openshift-route-certs) from /etc/letsencrypt/renewal/openshift-route-certs.conf produced an unexpected error: All authorizations were not finalized by the CA.. Skipping.
All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/openshift-route-certs/fullchain.pem (failure)

Any ideas much appreciated.
Not sure who maintains this repo these days... would be great to keep it alive.

Make at least the annotations compatible with cert-manager, so it may be easily replaced by cert-manager in the future.

Reference: https://github.com/jetstack/cert-manager

Is your feature request related to a problem? Please describe.

BC's Entrust account can only issue certificates to domains whose ownership has been validated through a CA Browser Forum-approved method. Could Certbot be able to perform domain validation?

Describe the solution you'd like

A Certbot plugin packaged with this appliance that performs domain validation using a method supported by Entrust.

Describe alternatives you've considered

Ask the ADMS-SD team to do some manual work (aka toil)

Additional context

This would bring the DevOps process for working with Entrust more in line with the DevOps process for working with Let's Encrypt.

@cvarjao @jujaga