Problem after uninstalling Let's Encrypt


My domain is:

My operating system is: Linux h2web13 3.14.59-imu

My web server is: Apache 2.2.x

My hosting provider, if applicable, is: infomaniak

I can login to a root shell on my machine: I don’t know

I’m using a control panel to manage my site : yes

I installed the Let’s encrypt SSL certificate on the site mentioned above. Unfortunately I had to delete it again since some parts of the site are on an external server and there is no possibility to install the certificate there. Browsers will therefore block some content loaded from this external server. This is why I went back to non-ssl via the infomaniak control panel. After this I get the SEC_ERROR_UNKNOWN_ISSUER errormessage.

When checking with the SSL certificate checker on the main issue seems to be “Certificate does not match name”.

I do not understand why there is a problem since I think I uninstalled the certificate completely and should therefore have the site back to http instead of https.

Strange thing is, when I restore to a backup from before installing the SSL certificate the first time the problem is not resolved.

I also tried redirecting the site via .htaccess. Hence I guess I might not have used the right rules.

Many thanks in advance for reading this. I hope you can give me hints on what to try.
Please let me know if you need additional information.


what do you want to achieve ? just a http site ? (if so, that works for me, but your browser may have cached the redirects to https, so you may been to clear your browser cache )


Hello @WebNRZH,

Your “problem” is that your site was/is sending the header Strict-Transport-Security and as you already visited your site, your browser cached that header, which means that the browser will try to access to https version of your site, no matter whether you put in your browser http://yoursite, the browser will always try to access https://yoursite

curl -I
HTTP/1.1 301 Moved Permanently
Date: Sat, 16 Jul 2016 17:38:15 GMT
Server: Apache
Content-Type: text/html; charset=iso-8859-1
Strict-Transport-Security: max-age=16000000; includeSubDomains; preload;  <--- this is the header

To solve this issue you should find where is that header used in your apache conf and change max-age=16000000 to max-age=0 and reload apache.



Thanks! Yes I just want to get back to http. I cleared the browser cache completely.


Bút that would only work when send through HTTPS.


He is still serving his site using https, a bad cert but you can access his site so it is still valid to modify the header.

@WebNRZH, clearing your cache should work only for you but the rest of your old visitors should do the same or they will try to access to your site via https and a beautiful warning in their browser saying that your site is serving a bad cert.

My advice, put again the Let’s Encrypt certificate just for those visitors that already used your web, change the strict header to max-age=0 and keep it there for at least a couple of months. In my opinion is better a mixed content warning that a red banner saying that your site is insecure.



No, don’t forget that cert warnings for HSTS domains cannot be overridden, so browsers that have seen the old header will never see the new one.


Just to be sure. I’ll have to put the following into my .htaccess file:

<FilesMatch "\.(html|htm|php|cgi|pl)$"> ExpiriesActive Off Header set Cache-Control "max-age=0, private, no-store, no-cache, must-revalidate" </FilesMatch>


That’s completely wrong, the Strict-Transport-Security header has no relation to the Cache-Control header. You need to find where Strict-Transport-Security was set (most likely in the https vhost) and change that to 0, note that you must have https enabled and use a valid cert for this to work. This needs to be left in place for the full 16000000 seconds (just over 6 months), unless your domain has been put on the preload lists in which case it needs to be forever.


Not according to the RFC:

8.4. Errors in Secure Transport Establishment

When connecting to a Known HSTS Host, the UA MUST terminate the
connection (see also Section 12 (“User Agent Implementation Advice”))
if there are any errors, whether “warning” or “fatal” or any other
error level, with the underlying secure transport. For example, this
includes any errors found in certificate validity checking that UAs
employ, such as via Certificate Revocation Lists (CRLs) [RFC5280], or
via the Online Certificate Status Protocol (OCSP) [RFC2560], as well
as via TLS server identity checking [RFC6125].


Thanks. So I have now installed the certificate again and I put the following into my .htaccess file:

Header set Strict-Transport-Security "max-age=0"

Sadly the problem is not yet solved. The content of ist not being loaded. I don’t care if there is still an SSL certificate active, but I need the content loding on this site. It is a login for our volunteers where they can manage, their data. Is there any way to have it not blocked?


The header is still being send with a positive value, looking at your hosting providers instructions you need to change it to

Header always set Strict-Transport-Security "max-age=0"

After that you can then redirect any pages that don’t work with https back to http.


@cool110 and @sahsanu: Thanks a lot for your help!
It worked out now. The login is available again and everything is just fine!
Let me know if you need any help in legal issues. I’m actually a lawyer and not a web programmer, as you surely have noticed from my mistakes and questions. :wink:

You guys are great sharing your knowledge! This is why I keep helping people with their problems too!

Here is what I put in the .htaccess in case anyone else is interested:

Header always set Strict-Transport-Security "max-age=0"

# SECTION BEGIN SubDomainOnFolder

RewriteEngine on
RewriteCond %{HTTPS} on
RewriteRule ^cug\$ [L,R=301]

All credits to this solution to @cool110 and @sahsanu!


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