Old certificate from godaddy getting in the way

Help
1

I own loutilities.com through godaddy. I believe I used to have an SSL certificate there, but have let it lapse. Now when I try to set up ssl certificate through letsencrypt, I believe the old (dead) certificate is being found from my browser. Is this going to get taken care of over time, or do I have to take some action?

If it will be taken care of over time, how long will it take?

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. https://crt.sh/?q=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: loutilities.com

I ran this command: sudo certbot --apache certonly -d loutilities.com

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for loutilities.com
Waiting for verification…
Cleaning up challenges
Resetting dropped connection: acme-v02.api.letsencrypt.org

IMPORTANT NOTES:

  • Congratulations! Your certificate and chain have been saved at:
    /etc/letsencrypt/live/loutilities.com/fullchain.pem
    Your key file has been saved at:
    /etc/letsencrypt/live/loutilities.com/privkey.pem
    Your cert will expire on 2019-04-04. To obtain a new or tweaked
    version of this certificate in the future, simply run certbot
    again. 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): Apache/2.4.6 (CentOS)

The operating system my web server runs on is (include version): CentOS Linux release 7.6.1810 (Core)

My hosting provider, if applicable, is: n/a

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

2

Hi @louking

your www-version and your non-www version are using the same self signed certificate (expired):

|E=root@loutilities.com, CN=loutilities.com, OU=SomeOrganizationalUnit, 
O=SomeOrganization, L=SomeCity, S=SomeState, C=-- |23.03.2017|23.03.2018
expired|
| --- | --- |

If you use certonly, you have to install the certificate manual. And you should create one certificate with both domain names (non-www and www).

3

Not sure what you mean. I only have installed (on my server) one certificate for loutilities.com (although I did try to create another one earlier for www.contracts.loutilities.com, which might be confusing things).

I think the cert with expiration of March 2018 was from godaddy, as mentioned.

This was created today. In the past when I used --certonly the certificates were installed on my server correctly.

[lking@loutility-server-digitalocean letsencrypt]$ sudo ls -l /etc/letsencrypt/live
total 32
drwxr-xr-x 2 root root 4096 Jan  4 12:59 loutilities.com
-rw-r--r-- 1 root root  740 Jan  4 06:30 README
4

Using certonly will not install the cert nor restart the web service.

5

I’m confused as this has worked in the past. I think I had to go to certonly because certbot was messing up my apache configuration files when I didn’t use it. Did the behavior change in the last year or so?

https://crt.sh/?q=loutilities.com shows the two certificates I tried to install today.

Are you suggesting I just remove the certonly from the certbot command, or also the --apache?

One thing I am going to check – I see a file /etc/ssl/certs/localhost.crt which I don’t remember installing. The server itself is loutilities.com, so maybe that’s the one getting in the way.

6

Yes I think that is what is happening. The cert localhost.crt looks like the one being found instead of the letsencrypt cert I created today.

I’ll follow https://access.redhat.com/documentation/en-us/openshift_enterprise/2/html/deployment_guide/creating_an_ssl_certificate1 to regenerate localhost.crt and report back.

But I wonder if I should instead be pointing localhost at the loutilities.com cert which is being renewed automatically by certbot?

7

I'm suggesting that you understand the effect of using certonly and the necessary steps required after issuance.

As for the localhost.crt - that needs to be fixed at where it is being used, not by changing/updating that cert:
Review your vhost config files and ensure the server names, aliases, ports, and certs are all correct.

8

I think I do understand what certonly does, but this is a support forum, so if my understanding is incorrect I hope someone would help me improve that.

My understanding, and from https://certbot.eff.org/docs/using.html#getting-certificates-and-choosing-plugins, is that certonly loads the certificate to the server, but does not update the apache configuration files (see Autorenew vhost ambiguity if interested). At least I think that is what is meant by “install”.

I was forced to do use certonly when I first started working with letsencrypt because the apache plugin wasn’t working correctly. I have my own work instructions now on how to edit the apache vhost configuration file and restart the web server after running certbot. Probably I don’t need the --apache switch, so maybe that’s what is causing some confusion on the part of @rg305 of what I am doing and why. And possibly I don’t need to use certonly any more. But my process seems to work and I don’t have a lot of time to play with this because I need to move forward with the process of creating this vhost and the application which will live on it.

In any case I have 8 vhosts running on this server by doing what I have been doing, all appearing to work fine with ssl.

It seems like the current localhost.crt file I have can’t be used because it expired in March. /etc/httpd/conf.d/ssl.conf references localhost.crt and localhost.key. Not sure where I configured the server itself to “be” loutilities.com but I’ll figure that out. It’s possible that was only in the localhost.crt/key files.

9

Modifying ssl.conf to use the following rather than localhost.crt seems to resolve the issue (based on https://www.digitalocean.com/community/tutorials/how-to-secure-apache-with-let-s-encrypt-on-centos-7?comment=68437 as well as common sense), at least in incognito window. Chrome seems to have cached the “not secure” status somewhere even while saying the certificate is valid, which clearly isn’t a topic for this forum.

SSLCertificateFile /etc/letsencrypt/live/loutilities.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/loutilities.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/loutilities.com/chain.pem
10

FWIW and completeness, using solution 2 in this post resolved the chrome certificate cache issue: https://serverfault.com/posts/688828/revisions

11

You may have forced two wrongs to be a right...
[But it is difficult to say without seeing your whole config.]

You can try searching for it with:
grep -Eri 'listen|servername|serveralias|root|sslcert|loutilities.com' /etc/apache/
[which should show you enough to get a feel for what is where and how]

12

I looked through the grep output and there was nothing there I didn’t expect. The original loutilities.com cert was created by openssl.

I’ve tried to work around by changing the server cert to www.loutilities.com but this didn’t work either because the loutilities.com certs are in the path. Tried to revoke the loutilities.com certs to get them out of the way, and not sure that worked as I expected. Yes I’ve made a bit of a mess.

Yeah, I think a little knowledge can be dangerous and I may have gotten myself into a hole with this domain. As I need to get some real work done (make a VHOST with a domain like app1.loutilities.com) and it’s starting to look difficult to get there from here I may need to create a new domain to base these apps on.

Thanks for the help you tried to offer.

13

I'm not quite understanding what you're describing here, but we can still try to help figure out what's going on if you can post the output of certbot certificates and sudo ls -lR /etc/letsencrypt, as well as any particular errors that you're seeing or behavior that's not what you want.

14

Thanks! Hmm, the issue I thought I was seeing yesterday isn't there now. Not sure what I was looking at. If I run into any more problems I'll let you know.

16

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