"along with the flag -i apache" - where do I need to put it?

I’m trying to install a wildcard SSL cert using Certbot rn.

It told me to run this command:
certbot certonly
–dns-cloudflare-credentials ~/.secrets/certbot/cloudflare.ini
-d example.com
-d www.example.com

Together “with the flag -i apache”

This is required to get AND install the cert.
But where exactly do I need to place the “-i apache”?



(meaning just issue the certificate but don’t install it) with

-i apache

(meaning use the Apache installer).

1 Like

It looks like your Apache configuration is broken at the moment. You will need to repair the configuration manually before Certbot is able to install a certificate to it.

Looking at what the problem is:

You should be able to work around this by commenting out line 33 of that file (prepend it with a #).

Then check whether apachectl -t works. If it does, try again with Certbot.

1 Like

Alright. We can try help you fix your redirect loop, but you will need to share your domain name and Apache configuration.

The output of this would be helpful to begin with:

apachectl -S
1 Like

root@XXX:~# apachectl -S
VirtualHost configuration:
*:443 XXX (/etc/apache2/sites-enabled/000-default-le-ssl.conf:2)
*:80 XXX (/etc/apache2/sites-enabled/000-default.conf:1)
ServerRoot: “/etc/apache2”
Main DocumentRoot: “/var/www/html”
Main ErrorLog: “/var/log/apache2/error.log”
Mutex default: dir="/var/lock/apache2" mechanism=fcntl
Mutex mpm-accept: using_defaults
Mutex watchdog-callback: using_defaults
Mutex rewrite-map: using_defaults
Mutex ssl-stapling-refresh: using_defaults
Mutex ssl-stapling: using_defaults
Mutex ssl-cache: using_defaults
PidFile: “/var/run/apache2/apache2.pid”
User: name=“www-data” id=33
Group: name=“www-data” id=33

Interestingly, although I think this is not the cause of your current problems, the documentation you referred to is probably wrong because it doesn’t mention that you have to remove the certonly text from the command line (as @_az) indicated. I’ve asked elsewhere if other people think this is a bug and if this text could be clarified to specify this directly.

Yea that’s not the cause of my current issue but I agree. The documentation says
“Run one of the commands in the “Examples” section of the instructions for your DNS provider, along with the flag -i apache.”

@_az Anything else that you need?

I didn’t realize you were using Cloudflare (apart from for just DNS) initially, which complicates matters somewhat.

In the past, some users have experienced redirect loops based upon what protocol Cloudflare uses to talk with your origin (i.e. the whole Strict vs Flexible SSL thing).

And in this case, I believe that Cloudflare is to blame for your issue. When I submit an HTTPS request directly to your origin server, it works fine:

$ curl -X GET -I --resolve www.proofcore.io:443:51.x.x.x https://www.proofcore.io
HTTP/1.1 200 OK
Date: Fri, 26 Jul 2019 03:10:16 GMT
Server: Apache/2.4.18 (Ubuntu)

As for how you solve the Cloudflare problem, I don’t really have the answer. It has something to do with the Universal SSL settings on your domain, but I don’t use Cloudflare’s CDN service so I’m not in a great position to give advice about it.

I disabled Cloudflare Universal SSL now…
That’s what I get now

Well yeah, if you intend to use their CDN at all, you must keep Universal SSL enabled.

I believe what’s happening is that

  1. The visitor is connected to Cloudflare via HTTPS (using Cloudflare’s certificate for your domain)
  2. Cloudflare is talking to your origin server over (insecure) HTTP.
  3. When the insecure (from Apache’s perspective, but not from the visitor’s perspective) request arrives to Apache, Apache does a redirect to HTTPS.
  4. Visitor receives a redirect to HTTPS, but they’re already using HTTPS from their perspective … so you have a redirect loop.

I can speculate that the way to fix it would be to change your Universal SSL setting from “Flexible SSL” to “Strict SSL”, so that Cloudflare talks to your origin over HTTPS only, avoiding the redirect loop.

Or don’t use the CDN at all (disable the “orange cloud” in your DNS) and let people connect to your server. That way they’ll actually see your wildcard certificate rather than Cloudflare’s.

But I think community.cloudflare.com or Cloudflare support would be able to answer that question better.

Yea looks like it works with strict mode enabled…this still is kinda problematic so I guess it’s best to delete let’s encrypt again for now…
any kind of guide for that?

While the Certbot Apache plugin can do automated installation, it can’t undo it. You need to be very careful when reverting to the previous state.

I think you can find backups of your Apache configuration, before Certbot touched it, in /var/lib/letsencrypt/backups/.

What’s problematic about the current setup?

Why make your website insecure?

I keep getting too many redirects now if I don’t use cloudflare strict mode, even tho I got rid of letsencrypt.
I was able to use flexible mode before without any issues.
Same issue with cloudflare disabled, what the fuck

It’s probably your browser caching the old 301 redirect. It’s working fine for me.

I’m testing in incognito mode all the time

shrug. Maybe try hit Ctrl-Shift-R while it’s redirect looping.

I can see your site in Firefox, Chrome and with curl.

Ok now it works but why does it show Let’s Encrypt as cert still?

Well, you still have Cloudflare CDN disabled for that domain, so you’ll be connecting directly to your origin server. That’s why you don’t see the Cloudflare certificate.

As for why the Let’s Encrypt certificate is still active (which I can confirm), that entirely depends on how you removed it initially:

You can use apachectl -S to identify the port 443 virtual hosts and disable those configuration files to no longer use that certificate.

But you’ll probably want to enable Cloudflare CDN and wait some time for DNS propagation, before you do the above.

can I simply delete those or are they required for the website to work properly?