Does the existing certificate needs to be revoked before proceeding with installing let's encrypt certificates?


#1

Hi people,

I’m relatively inexperienced in this domain and am looking for help with the following question.

I’m planning to install let’s encrypt certificate for a domain that uses a godaddy certificate already. It is not exprired yet but I would like to replace it with a let’s encrypt cert. Do I have to revoke the godaddy certificate first to proceed ahead or can I go ahead with installing let’s encrypt certificate ?

Thanks


#2

There’s never any reason to revoke a certificate (from any vendor) unless you believe that an unauthorized party has gained access to its private key.


#3

Thanks for the clarification. Will try installing the certs using certbot and post the results here.

Cheers!


#4

Following are the details of the commands I ran. It appears that the godaddy certificate is still active. I ran it twice and chose option 1 during the second time.

Any help would be greatly appreciated. Please do let me know if there is anything else that can help debug this - nginx config file for example.

Cheers

My domain is: galleri5.com

I ran this command: sudo certbot --nginx -d galleri5.com,www.galleri5.com,brands.galleri5.com --expand

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Cert not yet due for renewal

You have an existing certificate that has exactly the same domains or certificate name you requested and isn’t close to expiry.
(ref: /etc/letsencrypt/renewal/galleri5.com-0001.conf)

What would you like to do?


1: Attempt to reinstall this existing certificate
2: Renew & replace the cert (limit ~5 per 7 days)


Select the appropriate number [1-2] then [enter] (press ‘c’ to cancel): 1
Keeping the existing certificate
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/galleri5_nginx.conf
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/galleri5_nginx.conf
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/galleri5_nginx.conf

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.


1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you’re confident your site works on HTTPS. You can undo this
change by editing your web server’s configuration.


Select the appropriate number [1-2] then [enter] (press ‘c’ to cancel): 2
Traffic on port 80 already redirecting to ssl in /etc/nginx/sites-enabled/galleri5_nginx.conf
Traffic on port 80 already redirecting to ssl in /etc/nginx/sites-enabled/galleri5_nginx.conf
Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/galleri5_nginx.conf


Congratulations! You have successfully enabled https://galleri5.com,
https://www.galleri5.com, and https://brands.galleri5.com

You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=galleri5.com
https://www.ssllabs.com/ssltest/analyze.html?d=www.galleri5.com
https://www.ssllabs.com/ssltest/analyze.html?d=brands.galleri5.com


IMPORTANT NOTES:

  • Congratulations! Your certificate and chain have been saved at:
    /etc/letsencrypt/live/galleri5.com-0001/fullchain.pem
    Your key file has been saved at:
    /etc/letsencrypt/live/galleri5.com-0001/privkey.pem
    Your cert will expire on 2019-05-28. To obtain a new or tweaked
    version of this certificate in the future, simply run certbot again
    with the “certonly” option. To non-interactively renew all of
    your certificates, run “certbot renew”

  • If you like Certbot, please consider supporting our work by:

    Donating to ISRG / Let’s Encrypt: https://letsencrypt.org/donate
    Donating to EFF: https://eff.org/donate-le

My web server is (include version): nginx/1.10.0

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

My hosting provider, if applicable, is: Google Cloud

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): certbot 0.28.0


#5

Is that the only configuration file for your site? Can you confirm the SSLCertificateFile points to the Let’s Encrypt certificate? Is there perhaps somewhere else still a SSLCertificateFile pointing to the GoDaddy certificate?


#6

Yes it is symlinked to the nginx config file in the app directory. I thought along your lines and grepped for files that contain the filepath of godaddy cert too and the results were the current config file in which it was commented out and older config files.

In the config file I don’t see SSLCertificateFile but ssl_certificate and ssl_certificate_key

Server block for brands.galleri5.com

configuration of the server

server {
if ($host = brands.galleri5.com) {
return 301 https://$host$request_uri;
} # managed by Certbot

    listen  80;

    server_name brands.galleri5.com brands.galleri5.in brands.galleri5.co.in;
    charset utf-8;

    client_max_body_size 75M;

    location /jobs {
            alias //home/ubuntu/jobs/;
    }

    location / {
            alias //home/ubuntu/webbrandapp/;
            try_files $uri /index.html;
    }

}

server {
listen 443;
ssl on;
ssl_certificate /etc/letsencrypt/live/galleri5.com-0001/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/galleri5.com-0001/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
server_name brands.galleri5.com;

    charset utf-8;

    client_max_body_size 75M;

    location /jobs {
            alias //home/ubuntu/jobs/;
    }

    location / {
            alias //home/ubuntu/webbrandapp/;
            try_files $uri /index.html;
    }

}

Server block for galleri5.com

server {
if ($host = www.galleri5.com) {
return 301 https://$host$request_uri;
} # managed by Certbot

if ($host = galleri5.com) {
    return 301 https://$host$request_uri;
} # managed by Certbot


    # the port your site will be served on
    listen          80;

    # the domain name it will serve for
    server_name .galleri5.com .galleri5.in .galleri5.co.in 107.167.178.147; # substitute your machine's IP address or FQDN
    return 301 https://galleri5.com$request_uri;

}

server {
# the port your site will be served on
listen 443;

    ssl     on;
ssl_certificate /etc/letsencrypt/live/galleri5.com-0001/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/galleri5.com-0001/privkey.pem; # managed by Certbot

    # the domain name it will serve for
    server_name .galleri5.com .galleri5.in .galleri5.co.in; # substitute your machine's IP address or FQDN
    charset         utf-8;

    # max upload size
    client_max_body_size 75M;       # adjust to taste

---- More location blocks here ------------

location / {
alias //home/ubuntu/webapp/;
try_files $uri /index.html;
}
}


#7

Sorry, I’m used to Apache, not nginx, you’re totally right of course with the ssl_certificate directive.

It would be kinda strange if there is no working reference to the GoDaddy certificate file and still your nginx would serve it.

Although it should not be necessary (as you’re using the nginx installer plugin), you might want to try to reload your nginx manually and check again.


#8

Thanks for your quick response. Really appreciate it :slight_smile:

I tried restarting nginx manually few times already. All the files where the godaddy cert paths were mentioned had it commented out, except in the old config backup files.

I’ve even tried moving the godaddy certs elsewhere to see what happens but still when I load the website in Chrome I get Godaddy cert details!

The domain was purchased using Godaddy. Forgive me if it is a silly question but is it possible that this is implemented somehow using the godaddy control panel ?

Thanks again for your help so far.


#9

I think not. Your hostnames resolve to the IP 107.178.251.144, which is a Google Cloud IP address. Also, if I directly connect to the IP address on port 80, I’m getting a “Welcome to nginx!” webpage, something I wouldn’t expect from some GoDaddy webserver. Therefore, I must conclude one really connects to your webserver when connecting to your hostname(s) and not some GoDaddy server.

I think you really need to hunt for that GoDaddy certificate in your nginx webserver, assuming you’re searching the nginx files on the server of 107.178.251.144. Triple-check if you have to.


#10

Found the culprit. It appears that there is load balancer involved in the picture sigh I will coordinate with the concerned person and take it from here.

Thanks a ton again for your help!


#11

Changed the A record to point at the IP where https://brands.galleri5.com is hosted. Works like a charm now :wink: You might need to clear the dns cache from the browser.

Just want to thank you again for your inputs. Wouldn’t have been possbile without that.

Cheers to the community!


#12

But the base domain hostname and the www subdomain are still pointing to your load balancer. Was that intended?


#13

Yes that is intended indeed. Will do that at an appropriate time later. Immediate concern was to secure the sub-domain.

Cheers


closed #14

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