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., so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

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/’ does not exist or is empty.
    removed certbot:
  4. sudo yum remove certbot
  5. sudo yum install certbot python2-certbot-apache
  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/ 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):


I’m using a control panel to manage my site (no, or provide the name and version of the control panel):


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.


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?


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/ 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


Why not? Millions of domains are using Letsencrypt certificates.

Millions of working configurations :wink:


Certbot probably created based on It would probably be reasonable and easy to delete 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.)


Thanks Rip, this indeed does work!

Now back in the original state (“Certificate name mismatch”), which you can see right here:

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

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 and

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!

1 Like

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


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

1 Like


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

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

What I then do not understand, why does 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

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/ and make sure it points to:

Certificate Path: /etc/letsencrypt/live/
Private Key Path: /etc/letsencrypt/live/
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.

1 Like

Hi @Rip,

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

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

Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/
SSLCertificateKeyFile /etc/letsencrypt/live/
SSLCertificateChainFile /etc/letsencrypt/live/

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”


I suggest you try:

sudo a2ensite

remember to restart apache

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


1 Like

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/ /etc/httpd/sites-enabled/

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.


1 Like

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

sudo ln -s /etc/httpd/sites-available/ /etc/httpd/sites-enabled/

Please confirm the paths…

EDIT: remember to restart apache



Thanks Rip, confirmed the paths, executed command and symlink works; now 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.