That's all? This cannot be true.
Please show the output of the following command:
netstat -tpln | grep :443
Well, the output of apache2 -D -t DUMP_VHOSTS shows that you don't have any virtualhosts with port 443 configured. Furthermore, there is one vhost for port 80: baumangel-baurecht.de.
To find the redirect, look into post #17.
I'm out here.
ahm, nope:
apache2ctl -t -D DUMP_VHOSTS
shows indeed there are 443 vhosts configured, otherwise why else should the https request showing on the next domain with https? 
It looks like the only real problem you have is that Certbot hasn’t setup an SSL vhost for your baumangel-baurecht.de. domain.
You should be able to run Certbot again (assuming you use --apache or -i apache) and when prompted:
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/baumangel-baurecht.de.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 1 and then your Apache should be updated to actually use the certificate for your domain.
Upon running DUMP_VHOSTS again, you should now see a new entry for your domain.
1 Like
So why did you hide that information in the first place?
True, but I don't want to secure the domain, I just want a clean uninstall from this domain, so that the domain just run on port 80 as before
Because for a rollback to port 80 the configs for 443 are pretty useless
Well, you can find what’s causing the redirect, and remove it, which is what bytecamp already suggested earlier.
grep -REi "(RewriteRule|Redirect)" /etc/apache2
1 Like
for the affected domain, there is no output - all other domains have the syntax
/etc/apache2/sites-available/000-default: RewriteRule ^(.*)$ http://%1/$1 [R=301,L]
/etc/apache2/sites-available/000-default: Redirect "/" "http://www.maindomain.com/"
Update: I found out, if I rename the /docs/index.php (from the wordpress installation) and it apache has to take the index.html - it works, that means there is no forced https rediction anymore and it shows the index.html content. Only if I activate the index.php to run the wp site, the https redirect is active again.
There is no file from letsencrypt in the /docs/ directory anymore and LE doesn't modify the WP files (why should they), so what else?
You may want to also:
- Check your .htaccess file(s) for any redirects
- Check that the WordPress Site URL isn’t set to
https://...(https://codex.wordpress.org/Changing_The_Site_URL)
We this point already yesterday (#8): there is no redirection.
I placed manuel "http" entry with no effect ...
Update: I removed all the https entries in the wp database, even in the comments (which is completely rediculous, but desperate...)
Directly requesting any other existing resource does not result in a redirect, e.g.
$ curl -i http://baumangel-baurecht.de/wp-config.php
HTTP/1.1 200 OK
Date: Fri, 02 Mar 2018 10:48:48 GMT
Server: Apache/2.4.25 (Debian) mod_fcgid/2.3.9 OpenSSL/1.0.2l
Content-Length: 0
Content-Type: text/html; charset=UTF-8
$ curl -i http://baumangel-baurecht.de/wp-content/
HTTP/1.1 200 OK
Date: Fri, 02 Mar 2018 10:49:02 GMT
Server: Apache/2.4.25 (Debian) mod_fcgid/2.3.9 OpenSSL/1.0.2l
Content-Length: 0
Content-Type: text/html; charset=UTF-8
So it indicates that it’s not a VirtualHost-wide problem, and not likely to have been caused by Certbot either.
Here’s an experiment you can try. Replace index.php with a file just containing:
<?php phpinfo(); ?>
and try a curl request against it.
If it results in a redirect, the issue is your Apache configuration or an .htaccess directive.
if there’s no redirect, then the issue is inside WordPress.
Easy, definitive answer. Satisfaction guaranteed.
I’ve tested this already 2 days ago with the ofniphp.php in the directory. But for completion: the index.php is set with the phpinfo(); - no redirect, as expected. Try it - its still active.
The “easy” definitive answer thats is WP fault isn’t one, because exactly why? Before I installed the certificate, there was no problem at all, after installing - ok either. But not after removing the certificate, huge probs to go back on the port 80 with the site.
What has this to do with WP? Or does certbot change anything inside WP config files?
Well, it is an answer, because at this point we know for sure that you don’t need to worry about Apache or Certbot anymore. Neither of them are causing your troubles, and neither of them broke your WordPress site, either.
From what I can tell, WordPress thinks that its canonical URL begins with https://. I’m not a WordPress user, I don’t know why it is happening. Maybe it’s a plugin, maybe your theme, maybe the Site URL is somehow being forced to that value, we can’t see the inner workings of your CMS.
Perhaps a further experiment could be to try to change your Site URL to a sentinel value like http://wordpress.invalid, to confirm that the changes you’ve made to the Site URL (to force it to http://) are actually taking effect.
You may also find that you can solicit more informed answers about this issue from the WordPress community.
This issue isn't discussed there yet.
The thing is: its easy to delete the page and make it new from scratch, take a complete week, because you can't use a backup - only the one with the certs. And this is the point: if the user using WP and letsencrypt and this thread is not solved, any user has to expect that after removing the certificate having the same problems like here discussed.
Thats - an my week to rebuild the site - is the point why we have to figure out what this error caused.
In the meantime, I've looked and delete (even in the logs) the https referer - with no effekt. I've searched with "find / -type f -print0 | xargs -0 grep "https://baumangel-"" (and more) for the redirect. No changes.
Update: Issue is solved.
@_az you were right, it was a WP problem. The Plugin “really-simple-ssl” caused the problem. This plugin fixes the “unsecure” error and fixes the related path issues.
If you delete it, the page shows up without any redirection.
Thats it, Thanks for everyone for helping!
Hi.
I have a domain
Kmkamruzzaman.com
But i cannt pay any fees.
Thank you
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.