Using certbot if I already have nginx configured w/self-signed cert


#1

My domain is: ciab.ws

My web server is (include version): tomcat8

The operating system my web server runs on is (include version): Ubuntu 18.04.2

My hosting provider, if applicable, is: aws, digital ocean, hetzner (doesn’t matter for my question)

My question is fairly simple & straight forward.

I integrate Guacamole v1.0.0, tomcat8, mysql, nginx and up till last week just configured nginx with a self-signed certificate.

That has all been working fine for the past 2 years or so and I could connect to the cloud based Guacamole Proxy service using either Chrome, Chromium or Firefox using HTTPS… but of course I always got the warning since I was using a Self-Signed certificate.

I then finally got around to deciding to implement a valid CERT and used certbot successfully if I used my guacamole, tomcat8, mysql, nginx installation scripts but did not use my own nginx config for an unsigned certificate first.

Since my scripts are on Github for anyone to use. I know not everyone utilizing my scripts may have a Registered Domain Name and thus may want to use the Self-Signed Certificate route instead or until they get their own Registered Domain Name.

So my question is this…

Assuming I already have my own self-signed cert config:

/etc/nginx/sites-available/default
and
/etc/nginx/sites-enabled/default

Can I use Certbot if I just edit my /etc/nginx/sites-available/default file and delete my existing local domain names and replace them with just an underscore “_”

before

server_name ciab-guac www.ciab-guac;

after

server_name _ ;

I just want to know what lines in an existing “/etc/nginx/sites-available/default” file does Certbot expect to see and edit to add the new valid Certificate info.

Is there more that Certbot searches/parses for than just the:

server_name _ ;

thanks for any answers…
Brian


#2

If you use the nginx authenticator (–nginx), it will try to best match the requested name to a specific config/block.

If it is unable to match it exactly it “should” use the default match.

If that should fail you can always use the --webroot path for authentication.
[this may be simpler to troubleshoot and faster to implement]


closed #3

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.