Corrupted settings of web-server

My domain is: autolider.org

I ran this command: /usr/local/bin/certbot-auto --apache

It produced this output: I got working SSL-certificate, but then problems started. Described below

My web server is (include version): Apache/2.2.15 (Unix)

The operating system my web server runs on is (include version): CentOS release 6.8 (Final)

My hosting provider, if applicable, is: VPS

I can login to a root shell on my machine (yes or no, or I don’t know): yes (sudo su)

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): 0.37.1


After making the necessary settings directly on the site, HTTPS worked properly. But broken HTTP.
I don’t work like that, and I began to figure out what the problem was.
The first request for HTTP, I received “too many redirects”, Next requests added to my address bar a lot of extra parts of ‘install’ - the format is approximately the following:
http://autolider.org/install/install/install/.../install/install.php
When I tried any movement on the site, I received an error 404 (caching excluded).

First, I tried to manually roll back the httpd.conf file - and as a result, I received the source code of the scripts in the browser that I requested for execution from the browser.
When I began to suspect that the web server settings files were corrupted, I decided to roll back to the backup that I created right before the start of all the work of switching to HTTPS.
What exactly was corrupted - I still did not understand.
But before a complete rollback, I saved all the data from the “/etc/letsencrypt” folder, and also created a copy of the existing “almost working” httpd.conf file.
After the backup was restored - I saved the keys, certificates and VirtualHost parameters to the correct places, manually.
After all these manipulations, the site worked well on both HTTP and HTTPS.
Now i can’t have a command “certbot” or “certbot-auto”.

Next certificate renewals (after 90 days) will require repeating all of these procedures:
0 - backup of the server;
1 - execute instruction https://certbot.eff.org/lets-encrypt/centos6-apache;
2 - it is known that the web server settings will be corrupted;
3 - download new data from the “/etc/letsencrypt” folder;
4 - restore the backup copy of the server;
5 - upload new files of keys and certificates.

Main problem in all this is - points 0 and 4, only it will take about 2 hours of waiting.
Question: if I have the opportunity to manually retrieve the necessary data to be loaded into “/etc/letsencrypt” ?

Hi @berkut_0

your site doesn't really work. There are a lot of errors. Check the output of https://check-your-website.server-daten.de/?q=autolider.org#url-checks

  • you have ipv4 and ipv6. But your ipv6 doesn't work, only timeouts. That blocks your certificate renew, because Letsencrypt prefers ipv6.
  • There is a wrong redirect http + www to http://autolider.org without a / at the end. Result: Checking the validation file http://www.autolider.org/.well-known/acme-challenge/random-filename redirects to http://autolider.org.well-known/acme-challenge/random-filename.

Pinging and tracert to your ipv6 2a00:7a60:0:74a9::2 works. So check your Apache if there is a

Listen [::]:80
Listen [::]:443

And check, if your vHosts use

<VirtualHost *:80>

not an explicit ip address.

1 Like

I tried this addresses
http://autolider.org
http://autolider.org/
http://www.autolider.org
http://www.autolider.org/
https://autolider.org
https://autolider.org/
https://www.autolider.org
https://www.autolider.org/

I not see problems with / at the end, all links redirecting to https://autolider.org/, anyway i get responce code 301 - index.php redirectiong if $_SERVER[‘HTTPS’] not set or not equal ‘on’

All that you specified (Listen or VirtualHost)
If i change something from this - i get “connection refused”
But, in process of clean all trash in httpd.conf i deleted all not my comments, and commented all “NameVirtualHost” directives - site is working.
I’m using my 100 % working example.
Also, i sorted all records - my data at the bottom. So, can you see this and help me ?
https://pastebin.com/RJC5djZk

If I turn off “#” beside already commented “Listen” directives - site is “connection refused”. Right working only “Listen 80”.

However, my initial question was different.
Can I manually obtain certificates for uploading to /etc/letsencrypt ?

You can't check that with a browser. Browsers cache suche redirect results, so you see always the result of your first visit.

You must use online tools to check that or tools like curl -> command line.

As written: You need Listen [::]:80, they are inactive. And you have an ip address

<VirtualHost 185.25.116.169:443 >

instead of *.

I don't understand your initial question. If a tool like certbot has it's own directory logic, you shouldn't change something or copy files in these directories (out is ok). That's always bad. If you have a not working configuration, you should fix your configuration. Using Letsencrypt -> Automation -> manual actions are always bad, Letsencrypt certificates are only 90 days valid.

1 Like

So, I figured out why the site did not work through IPv6 - it was all about “ip6tables” settings.
Also fixed various problems in .htaccess.

About your site link checking tool.

  1. Problems with light red marker (without a category letter) associated with Nameserver.
    If I understood correctly, these problems are beyond my competence. The same applies to all problems of category “X”.
    Or, can I do something about this?
  2. Category ‘I’ problem, I do not see any details of this problem. Browser and DevTools do not show any errors - everything works fine for me.
    What exactly needs to be fixed?
  3. Problem of category “O” (current state of domain check) - I can not solve this problem using Let’s Encrypt and Certbot, because root certificate uses SHA1 encryption algorithm. Personal certificate uses SHA256.
    Or, can I somehow influence it too?
  4. List of problems associated with current SSL certificate (I understand that this is so):
  • “warning: HSTS preload sent, but not in Preload-List”;
  • all problems of category “N”;
  • “Warning: No CAA entry with issue / issuewild found, every CAA can create a certificate”.
    Will all these problems be fixed after using Certbot correctly?

ns316.inhostedns.org isn't your server. So you can't fix it.

Please read the output:

It's the problem that browsers and dev tools don't show such problems. But there are http links.

The root certificate isn't relevant. If the root certificate would be relevant, every site with a Letsencrypt certificate would have a Grade O. Please read the output:

Old connection: SHA1 as Hash Algorithm is deprecated. Switch to SHA256 or SHA384. If your certificate has SHA256, first check your domain via ssllabs.com and update weak Cipher Suites. Forward Secrecy support is required. The part "Cipher Suites" should have a preference. First Cipher Suite with SHA instead of SHA256 or higher - that's the problem, change that. If that doesn't help, check if there is an old Firewall / router or something else, that supports only SHA1. Update that component.

Checking your site with Ssllabs the result is terrible. Grade C, Poodle, RC4, no FS, SSL3 active.

All problems have nothing to do with Certbot.

Updated the message:

Warning: HSTS preload sent, but not in Preload-List. Never send a preload directive if you don't know what preload means. Check https://hstspreload.org/ to learn the basics about the Google-Preload list. If you send a preload directive, you should immediately add your domain to the HSTS preload list via https://hstspreload.org/ . But it's not possible to check that. If Google accepts the domain: Note that new entries are hardcoded into the Chrome source code and can take several months before they reach the stable version. So you will see this message some months. If you don't want that or if you don't understand "preload", but if you send a preload directive and if you have correct A-redirects, everybody can add your domain to that list. Then you may have problems, it's not easy to undo that.

All N-problems are port 993 / 995. Your mailserver uses a self signed certificate. May be critical, may be not relevant. May be you can't change that.

Updated the comment:

Warning: No CAA entry with issue/issuewild found, every CAA can create a certificate. Read DNS Certification Authority Authorization - Wikipedia

1 Like

Maybe i can change this Nameserver ?
And how i can fix CCA ?

I may not understand something, so I apologize for any misunderstandings.

  • Content issues (category "I") resolved.
    I immediately suspected that problem was in presence of "http://" links, and I replaced all these links with relative ones, that I found in page source code. About CSS file I learned from you.
  • All problems on ssllabs.com resolved, rating is "A+". SSL Server Test: autolider.org (Powered by Qualys SSL Labs) .
  • HSTS preload - HSTS Preload List Submission ; waiting for update data.
  • What about category "N" problems.
    For a long time ago, I created self-signed certificates, I did it all manually.
    Will these problems be resolved after applying Certbot?
    And will Certbot work properly?

Please read

then check, what Certbot is doing.

https://certbot.eff.org/docs/using.html

Looks like you mix things that are completely different.

I don't mix them.
I understand that Let's Encrypt is certificate (free certificates service). Certbot is program auto-installation of certificates.
But I also understand that Certbot installs certificates from Let's Encrypt. Turns out - these relate each other.

I am going to backup of server, and apply instruction of Certbot.
Could it be that I will have to restore backup after applying this instruction?

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