All BASIC Sandbox

[AIR]

That certificate looks like it is still self-signed and expired.

sandbox.allbasic.info:8181 uses an invalid security certificate. The certificate is not trusted because it is self-signed. The certificate expired on December 5, 2018, 6:07:17 PM GMT-5. The current time is December 8, 2018, 1:16 AM.

[John]

The solution may be to reference the Plesk generated certs that don't have a problem renewing. Maybe a symbolic link to where Gitlab is looking for its certificate to where Plesk is storing its allbasic.info cert would solve the handshake issue?

[John]

I think the root of the problem was Let's Encrypt was unable to validate through the proxy and kept on trying until it exhausted cert limits.

[AIR]

The solution may be to reference the Plesk generated certs that don't have a problem renewing. Maybe a symbolic link to where Gitlab is looking for its certificate to where Plesk is storing its allbasic.info cert would solve the handshake issue?

No, that wouldn't work because the cert would have no info about the sandbox.

What you need to do is add the sandbox.allbasic.info subdomain to the cert.  https://www.plesk.com/blog/product-technology/lets-encrypt-plesk/

[AIR]

I think the root of the problem was Let's Encrypt was unable to validate through the proxy and kept on trying until it exhausted cert limits.

Then you might want to look at your proxy setup, because I have an NGINX proxy for my GOGS (git) host on my VPS and have never had issues.

Are you using a subdomain for the sandbox, or an alias?  If the latter, I'm not sure if LE will work with that.

[John]

Now that GitLab isn't flooding Let's Encrypt for certs, I will be able again to use Plesk to create a cert for sandbox.allbasic.info. I might just have to wait it out.

The sandbox is a true sub-domain.

I'm doing a proxy with Apache settings not nginx.

The reverse proxy settings have one function. To eliminate having to use :8181 in the url.

A reverse proxy server is a type of proxy server that typically sits behind the firewall in a private network and directs client requests to the appropriate backend server. A reverse proxy provides an additional level of abstraction and control to ensure the smooth flow of network traffic between clients and servers.

I also wonder why GitLab is still looking at its expired cert if Let's Encrypt is disabled? What if I rename the cert?

Only allbasic.info am I not able to create Let's Encrypt certificates for.

[John]

The solution may be to focus on getting GitLab's Let's Encrypt to validate through the proxy. HTTPS dosn't like talking on :8181 to validate its certs.

[AIR]

I also wonder why GitLab is still looking at its expired cert if Let's Encrypt is disabled? What if I rename the cert?

Only allbasic.info am I not able to create Let's Encrypt certificates for.

I've attached httpd.conf, nginx.conf and gitlab.rb files for sandbox.allbasic.info.

Your httpd.conf has this for the sandbox vhost:
      SSLEngine on
      SSLVerifyClient none
      SSLCertificateFile /usr/local/psa/var/certificates/cert09PuPLH

AIR.

[AIR]

What does the LE log show?

[John]

Should those entries be delete now there is no Plesk generated LE  cert for sandbox.allbasic.info only allbasic.info?

Where do I find the LE log?

[AIR]

/var/www/vhosts/default/htdocs/.well-known/acme-challenge/

Does that path exist?

[John]

The question I have is if GitLab was able to validate its initial cert, what did the Plesk interface do to break GitLab from renewing the cert?

[AIR]

The question I have is if GitLab was able to validate its initial cert, what did the Plesk interface do to break GitLab from renewing the cert?

Is it possible that it altered the .htaccess file?  The only time I've had an issue with LE is when I configured a restriction on a folder (was testing video conferencing) to require direct authentication.  The LE service couldn't access the .well-known folder structure because public access to the parent folder was blocked.

[John]

The only thing added to this was the proxy reverse to eliminate :8181 from the URL. It worked fine before and after this httpd.conf addition.

Maybe if I disable the proxy reverse and enable LE in GitLab, maybe it will renew when the limit expires?
 

[AIR]

The only thing added to this was the proxy reverse to eliminate :8181 from the URL. It worked fine before and after this httpd.conf addition.

Maybe if I disable the proxy reverse and enable LE in GitLab, maybe it will renew when the limit expires?

Maybe, but might be best to renew manually to avoid any issues with flooding the LE system and locking yourself out indefinitely...if you use certbot and the renew option, it will only request a renewal if it is needed, otherwise it will inform you that it isn't needed and won't submit an actual request.

On my server, I did it like that the first few times, and then put the command in a script and created a cron job for it.

The script is simple:

Code: Bash

1. #!/bin/bash
2.  
3. sudo certbot renew
4.  

And the crontab file for ROOT contains:

Code: Text

1. @monthly /home/riveraa/bin/renew
2.  

Which as you can guess, runs the "renew" script once a month.

AIR.