Acme-companion docker-compose returns CERT_AUTHORITY_INVALID

[zlonghofer]

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: https://longhofercloud.twilightparadox.com

I ran this command: sudo docker-compose up -d

docker-compose.yml

version: '3.9'

services:
  db:
    image: mariadb:10.6
    command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW --innodb-file-per-table=1 --skip-innodb-read-only-compressed
    restart: always
    volumes: 
      - './db:/var/lib/mysql'
    environment:
      - MYSQL_ROOT_PASSWORD=REDACTED
      - MARIADB_AUTO_UPGRADE=1
    env_file:
      - db.env #MYSQL_PASSWORD, MYSQL_DATABASE, MYSQL_USER
  
  redis:
    image: redis:alpine
    restart: always
  
  app:
    image: nextcloud:apache
    restart: always
    volumes:
      - './nextcloud:/var/www/html'
      - './data:/var/www/html/data'
    environment:
      - VIRTUAL_HOST=longhofercloud.twilightparadox.com
      - LETSENCRYPT_HOST=longhofercloud.twilightparadox.com
      - LETSENCRYPT_EMAIL=REDACTED
      - MYSQL_HOST=db
      - REDIS_HOST=redis
    env_file:
      - db.env #MYSQL_PASSWORD, MYSQL_DATABASE, MYSQL_USER
    depends_on:
      - db
    networks:
      - proxy-tier
      - default
  
  cron:
    image: nextcloud:apache
    restart: always
    volumes:
      - './nextcloud:/var/www/html'
    entrypoint: /cron.sh
    depends_on:
      - db
      - redis
  
  proxy:
    build: ./proxy
    restart: always
    ports:
      - 80:80
      - 443:443
    labels:
      com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy: "true"
    volumes:
      - './certs:/etc/nginx/certs:ro'
      - './vhost.d:/etc/nginx/vhost.d'
      - './html:/usr/share/nginx/html'
      - '/var/run/docker.sock:/tmp/docker.sock:ro'
    networks:
      - proxy-tier
  
  letsencrypt-companion:
    image: nginxproxy/acme-companion
    restart: always
    volumes:
      - './certs:/etc/nginx/certs'
      - './acme:/etc/acme.sh'
      - './vhost.d:/etc/nginx/vhost.d'
      - './html:/usr/share/nginx/html'
      - '/var/run/docker.sock:/var/run/docker.sock:ro'
    networks:
      - proxy-tier
    depends_on:
      - proxy

networks:
  proxy-tier:

volumes:
  acme:
  db:
  data:
  certs:
  html:
  nextcloud:
  vhost.d:

Navigating to my domain on local network produced:

NET::ERR_CERT_AUTHORITY_INVALID
Subject: letsencrypt-nginx-proxy-companion

Issuer: letsencrypt-nginx-proxy-companion

Expires on: Nov 3, 2023

Current date: Nov 5, 2022

PEM encoded chain: 

The PEM encoded chain listed was the same as the one stored at ./certs/default.crt

Output of tree certs (the docker volume for the certs):

certs
|-- default.crt
|-- default.key
|-- dhparam.pem
`-- longhofercloud.twilightparadox.com

Navigating to my domain outside LAN produced:
504 Gateway Time-out
nginx/1.21.6
ATT Router (192.168.1.254) Firewall --> NAT/Gaming shows TCP/UDP: 80 and TCP/UPD: 443 open to the host machine.

My web server is (include version): nginx/1.21.6, I think.

The operating system my web server runs on is (include version): Arch Linux

My hosting provider, if applicable, is: freedns.afraid.org?

I can login to a root shell on my machine (yes or no, or I don't know):
Yes.

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
No.

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
I don't know.
Output of
Output of sudo docker exec <CONTAINER ID> certbot[-auto] --version:
OCI runtime exec failed: exec failed: unable to start container process: exec "certbot[-auto]": executable file not found in $PATH: unknown
How do I execute this command through docker?

I believe my problem may be at docker-compose.yml --> services: --> app: --> environment: --> VIRTUAL_HOST and LETSENCRYPT_HOST. Do I need to change these values to access the nextcloud app container at my domain?

[Bruce5051]

Hello @zlonghofer, welcome to the Let's Encrypt community.

Here is a list of issued certificates for crt.sh | longhofercloud.twilightparadox.com
While here is a list of issued certificates for https://crt.sh/?q=twilightparadox.com

You have it the Rate Limits here Let's Debug

Testing and debugging are best done using the Staging Environment as the Rate Limits are much higher. Rate Limits are per week (rolling).

[zlonghofer]

Thanks for the quick reply.

I will read more on the staging environment before moving forward.

I believe this means I'm sharing the rate limits with other people renting subdomains on this domain. Since I cannot attempt another certificate renewal before the elapsed time and am sharing the domain, I would not know if another certificate was available -- which means one solution would be to check Let's Debug before trying to issue a cert? With the best solution being buying a separate domain.

When I visit your second link the list of issued certificates for twilightparadox.com and sort by Logged At, the most recent shows 2020-06-02 -- this doesn't seem correct?

[Bruce5051]

@zlonghofer

Logged At, the most recent shows 2020-06-02

Seem a bit odd to me as well, but maybe there is something going with a large number of certificate with https://crt.sh/ that I am unaware of.

Then check here:
https://search.censys.io/certificates?q=twilightparadox.com

[MikeMcQ]

@Bruce5051

Seem a bit odd to me as well, but maybe there is something going with a large number of certificate

Yes, that can happen with crt.sh when there is a very large number of results to a search

As you suggested, censys.io is a good alternative in those cases. Even if it is much more difficult to use and aggregate results.

Sometimes you can get crt.sh results by starting in Advanced options screen and ticking "Exclude Expired" and "Deduplicate". Doesn't always help. But I did get one to work that way (top of screen):

[rg305]

@zlonghofer

  letsencrypt-companion:
    image: nginxproxy/acme-companion
    restart: always
    volumes:
      - './certs:/etc/nginx/certs'
      - './acme:/etc/acme.sh'
      - './vhost.d:/etc/nginx/vhost.d'
      - './html:/usr/share/nginx/html'
      - '/var/run/docker.sock:/var/run/docker.sock:ro'
    networks:
      - proxy-tier
    depends_on:
      - proxy

It seems like the only image able to update the certs is using acme.sh.
But the path /etc/nginx/certs is not the default for acme.sh certificates.
Where did you get the yml file?

[zlonghofer]

The yml is adapted from the Docker Nextcloud example on github.

Alright. I'm trying to understand this. According to the acme-companion container github, the proxy container should have three writable volumes (etc/nginx/certs, /etc/nginx/chost.d, and /usr/share/nginx/html). Then it says /etc/nginx/certs should be read-only. This seems like a contradiction. (Or does this mean that it's designed for only acme-companion to write the certs?)

At this point, I can't identify where a problem would occur because of the yml. Docker-compose should work the same as the acme-companion example to start the nginx proxy, then start the letsencrypt to request the certs, then start the app, with VIRTUAL_HOST and LETSENCRYPT_HOST passed, and return a value.

Side note: I haven't introspected acme.sh. Acme-companion requires two environment variables at the container level, and I am assuming that acme.sh will only attempt to issue a certificate if one is not found in the certs volume. At this point, I'm treating acme.sh as a black box. I found where the script is located when I start up the container, and sudo docker exec <container ID> cat acme.sh and sudo docker exec <container ID> acme.sh --help both work. I'm assuming the NextCloud app container doesn't need to expose a port because if the app needed to expose a port, I assume the yml example would explicitly expose those ports if it was necessary (and it's only using 80 & 443?).

I just checked Lets Debug, and the rate limits are currently not problematic. Before I request a cert, I want to know what I'm doing. I replaced my domain with acme-staging-v02.api.letsencrypt.org, and now I have two directories under my certs volume:

certs
|-- default.crt
|-- default.key
|-- dhparam.pem
`-- longhofercloud.twilightparadox.com
`-- acme-staging-v02.api.letsencrypt.org

Unfortunately, each directory is empty after running sudo docker-compose up [-d], and I would expect to "debug" by trying to access the domain. Any debugging advice or links to such advice would be greatly appreciated.

Thanks.