You have one of those? What HAVE we been doing then? That should instantly solve things if it's configured correctly.
To clarify, you mentioned the history of your company so I gave you a link to the whole certificate history for pacifictrustees.com:
I just checked in with the vendor. He does not have a panel. Its all done through cmd
So firstly, I wanted to check through my server for the source code files as we did not want to pay our vendor to change some values on the website. After that I noticed that ubuntu needed to update, so i went ahead and updated it to the latest version. After that, unknowingly, I downloaded apache without realizing we were using nginx already. Before all of this, our team was still able to access it internally. After we found out about pact online not being able to be accessed, I went ahead and checked out how to renew the certificates and did quite a number of renew commands. Only just today I found out that Apache could've been the problem and uninstalled it. Right now, here we are.
I think this is the easiest and quickest fix right now, no?
The absolute fastest for a one-shot would be DNS. As long as you can add the dns txt records and install the cert and key, you can get updated in a few minutes. This won’t solve your config issue, but it will get you running for now.
There’s a chance @9peppe may be able to get you going through http though, which is a better permanent fix.
Ok, let’s see what we have here:
Run these commands:
crontab -lsystemctl list-timersdocker ps
I think I undestood what the problem is, what mounts can the nginx container access?
docker container inspect --format='{{json .Mounts}}' $CONTAINER_NAME
yes, that’s what I was looking for.
show me the files in /etc/letsencrypt/renewal/ (contents included)
1 Like
etdemo.conf:
renew_before_expiry = 30 days
version = 0.8.1
cert = /etc/letsencrypt/live/etdemo.pacifictrustees.com/cert.pem
privkey = /etc/letsencrypt/live/etdemo.pacifictrustees.com/privkey.pem
chain = /etc/letsencrypt/live/etdemo.pacifictrustees.com/chain.pem
fullchain = /etc/letsencrypt/live/etdemo.pacifictrustees.com/fullchain.pemOptions used in the renewal process
[renewalparams]
authenticator = webroot
installer = None
account = a8987bc9fe1da02f81fb5466c61d87be
[[webroot_map]]
etdemo.pacifictrustees.com = /mnt/nginx/html
etrust.conf:
renew_before_expiry = 30 days
version = 0.8.1
cert = /etc/letsencrypt/live/etrust.pacifictrustees.com/cert.pem
privkey = /etc/letsencrypt/live/etrust.pacifictrustees.com/privkey.pem
chain = /etc/letsencrypt/live/etrust.pacifictrustees.com/chain.pem
fullchain = /etc/letsencrypt/live/etrust.pacifictrustees.com/fullchain.pemOptions used in the renewal process
[renewalparams]
authenticator = webroot
installer = None
account = a8987bc9fe1da02f81fb5466c61d87be
[[webroot_map]]
etrust.pacifictrustees.com = /mnt/nginx/html
Ok. let’s try with certbot renew --dry-run and see what happens.
I’ll do it tomorrow yeah. I’ve left the office already. You have a great day and we’ll communicate tomorrow
ok, it says “likely firewall problem”: do you have any idea why?
It was most likely the firewall blocking the port connection. As seen in the original query, it even stated that it is likely a firewall problem. What can I configure in my firewall settings to solve this?
The difference between the dry run statement and the crontab -l command is after produced an unexpected error.
Failed authorization procedure. etdemo.pacifictrustees.com (http-01): urn:ietf:params:acme:error:connection :: The server co uld not connect to the client to verify the domain :: Fetching http://etdemo.pacifictrustees.com/.well-known/acme-challenge/l7NTwIvJl3s Rmnk2V818FL59rDybVl_zF5KpETYulWs:
That depends on your firewall. You should read its manual to understand how to configure it, and either open port 80 permanently or open it just for the time needed to validate, using certbot's hooks as I've shown you above.
The thing is, I've opened it already
