Could not open configuration file /etc/letsencrypt/options-ssl-apache.conf: No such file or directory

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:

bikegeartracker.com

I ran this command:

  1. sudo certbot --apache
    first time this resulted in a “normal” flow, but checking the certificate @ SSL labs said it was incorrect (naming);
    I then removed the certificates:
  2. sudo certbot delete
    tried again
  3. sudo certbot --apache
    got following error: /etc/letsencrypt/live/bikegeartracker.com/cert.pem’ does not exist or is empty.
    removed certbot:
  4. sudo yum remove certbot
    reinstalled
  5. sudo yum install certbot python2-certbot-apache
    Re-tried:
  6. sudo certbot --apache

It produced this output:

httpd: Syntax error on line 355 of /etc/httpd/conf/httpd.conf: Syntax error on line 11 of /etc/httpd/sites-available/bikegeartracker.com-le-ssl.conf: Could not open configuration file /etc/letsencrypt/options-ssl-apache.conf: No such file or directory

My web server is (include version):

Apache/2.4.6 (CentOS)

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

CentOS Linux 7 (Core)

My hosting provider, if applicable, is:

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 1.5.0

1 Like

Hi @Thomasvdw

that breaks your configuration.

  • use your backup. If you delete files, you have a backup. If not, you shouldn't delete files
  • remove the port 443 vHost (or)
  • install a self signed certificate

Why do you delete certificates that are used? That's always wrong.

2 Likes

To put it differently; is there a way to in the future have this domain with a valid certificate, or is that out of the question after this mistake? I expect the certificates that were there would have expired in ~3 months, right?

@Thomasvdw

You'll have to manually remove the reference TO /etc/letsencrypt/options-ssl-apache.conf AND any references to certificates that have been deleted FROM /etc/httpd/sites-available/bikegeartracker.com-le-ssl.conf and restart apache.

Rerun Certbot.

  1. Run regular backups.
  2. Don't delete anything needed by your configuration and expect it to continue to work.

Come back to the forum and let us know how it worked.

Hope this helps
Rip

3 Likes

Why not? Millions of domains are using Letsencrypt certificates.

Millions of working configurations :wink:

2 Likes

Certbot probably created bikegeartracker.com-le-ssl.conf based on bikegeartracked.com.conf. It would probably be reasonable and easy to delete bikegeartracker.com-le-ssl.conf in its entirety rather than somehow editing it to remove references to deleted certificates (it probably can't be edited into a valid form without referencing these files). It's almost certain that this is the only location of invalid references and that nothing will be harmed by deleting it if it wasn't modified manually and if HTTPS already doesn't work for that domain with the current configuration.

I think it's quite legitimately confusing that certbot delete will result in a broken configuration when used to delete certificates that are only referenced in virtual hosts that were created by Certbot itself. It's one thing to say that randomly manually deleting files in /etc will break one's configuration, but in this case it's possible to break the configuration simply by using certbot run followed by certbot delete, which I think is counterintuitive and not ideal. I'm not sure what the best behavior from Certbot would be in this case. (One challenge here is that Certbot doesn't know whether the user has also modified other software configurations to reference the certificates that are going to be deleted.)

4 Likes

Thanks Rip, this indeed does work!

Now back in the original state (“Certificate name mismatch”), which you can see right here: https://www.ssllabs.com/ssltest/analyze.html?d=www.bikegeartracker.com

Any suggestions how to fix that? I suppose it is because it previously (on a different IP) did have a valid certificate, as I had to completely move my old server, unable to retrieve the certificate used there.

1 Like

That did indeed confuse me; it seems the certbot really can only go one way. If you want to go back, it’s not as simple as one might suspect from the command “certbot delete”.

1 Like

@Thomasvdw
Moving forward is a good thing.

If memory serves, (If I am mistaken I guarantee I will be corrected) you should be able to run the command certbot without additional tags or configuration elements.

Certbot should give you a list of all of your domains (and it looks like you have quite a number) including bikegeartracker.com and www.bikegeartracker.com.

There should be an option to EXPAND the certificate with additional domains in your configuration. You can’t put more than 100 entries into a single cert but you can use multiple certs.

Hope this helps!
Rip

2 Likes

When I grow up, I wanna be like you! :relaxed:

4 Likes

I think what you're thinking of is certbot certificates. :slight_smile:

2 Likes

@schoen

When I run “certbot certificates” I get the following result:

Found the following certs:
Certificate Name: bikegeartracker.com
Serial Number: 479e5c700b9aedbb2e02904feda0592661e
Domains: bikegeartracker.com www.bikegeartracker.com
Expiry Date: 2020-10-20 17:12:17+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/bikegeartracker.com/fullchain.pem
Private Key Path: /etc/letsencrypt/live/bikegeartracker.com/privkey.pem

What I then do not understand, why does bikegeartracker.com show the following:

  • the valid period does not match the result of “certbot certificates” and the certificate is not trusted. Any suggestions on how can this be overcome?
1 Like

@Thomasvdw
Your configuration is using a “self signed” certificate.
CRT.SH shows that you have obtained 4 new certs yesterday.

Check your /etc/httpd/sites-enabled/bikegeartracker.com-le-ssl.conf and make sure it points to:

Certificate Path: /etc/letsencrypt/live/bikegeartracker.com/fullchain.pem
Private Key Path: /etc/letsencrypt/live/bikegeartracker.com/privkey.pem
EDIT: remove erronious self-signed cert reference
and restart apache.

NOTE: earlier in this thread i asked you to make changes to “/sites-available/” in error (just caught it) OOPS isolated too long… :mask:

Hopefully this will get you on the right track.
Rip

2 Likes

Hi @Rip,

thanks for your quick response! If I look into /etc/httpd/sites-enabled/ there is no file named “bikegeartracker.com-le-ssl.conf”, there is only “bikegeartracker.com.conf”…

Now I think you perhaps mean /etc/httpd/sites-available/; this does contain the “bikegeartracker.com-le-ssl.conf” file, which contains following;

Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/bikegeartracker.com/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/bikegeartracker.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/bikegeartracker.com/chain.pem

I see this does not contain “fullchain” but just “chain”. The /live directory is not accessible (probably rightfully so ;)), so I can’t check if “…/fullchain” actually exists. Any thoughts?

EDIT: ofcourse I can check, I just didn’t know the command. I can confirm the “…/fullchain.pem” file does not exist.

Let me know how I can thank you afterwards, happy to buy you beer/pizza for your help! :slight_smile:

1 Like

Hello @Thomasvdw

Thank you for looking closer and pointing this out.
You are correct. I use a different OS and there is a different file structure. MY BAD.
That said you should be able to enable the site with “a2ensite”

/etc/httpd/sites-available/bikegeartracker.com-le-ssl.conf

I suggest you try:

sudo a2ensite bikegeartracker.com-le-ssl.conf

remember to restart apache

Should get you going…
Let us know how it turns out!

Rip

2 Likes

Hi Rip,

Thanks for the suggestion; I see a2ensite creates a symlinks within /etc/apache2/sites-enabled. But on my Centos 7 distribution this functionality is not available.

I suppose the alternative suggested for Centos distributions here would have the same result:

sudo ln -s /etc/httpd/sites-available/bikegeartracker.com.conf /etc/httpd/sites-enabled/bikegeartracker.com.conf

Is that correct? (reading on a2ensite functionality does not make it obvious for me)

OK. I am not a centOS expert. There are some here and maybe one of them can jump in to save the day.

If your sites-enabled has symlinks to sites-available, then it would be fair to consider creating your own symlinks. You could just copy the file to sites-enabled, but this is NOT “best practice”. (disclaimer)

The article you posted seems reasonable. But again… What is the correct and sanctioned method to enable a site on centOS? This eludes me.

I don’t want you to screw up your config by taking shortcuts.

@schoen has participated in this thread, maybe he can shed some light.

Rip

2 Likes

Seems your article is a good way to go…
Googled and found “second and third witnesses”

sudo ln -s /etc/httpd/sites-available/bikegeartracker.com-le-ssl.conf /etc/httpd/sites-enabled/bikegeartracker.com-le-ssl.conf

Please confirm the paths…

EDIT: remember to restart apache

Rip

3 Likes

Thanks Rip, confirmed the paths, executed command and symlink works; now bikegeartracker.com-le-ssl.conf exists within /etc/httpd/sites-enabled/.

Restarted apache, but nothing seems to really have changed on the domain, as it still mentions “not secured” (in Dutch) Capture

Don’t really understand it anymore to be honest :slight_smile: Any thoughts?

1 Like

@Thomasvdw Ik heb ook geen ervaring met CentOS, maar op zich zou dat ook niet nodig moeten zijn. Apache heeft namelijk een commando waarmee je een soort “uitdraai” van alle actieve VirtualHosts kunt krijgen, waardoor we wat meer inzicht kunnen krijgen in hoe je Apache-configuratie er precies uitziet.

Kun je a.j.b. apachectl -S draaien en de uitkomst hier plaatsen? Dan zien we daarna wel weer verder.

Oh en het zou helpen als je bepaalde outputs van commando’s tussen drie “backticks” (```, op een eigen lijn boven en onder de tekst) kunt plaatsen.

3 Likes