Domain is under attack and SSL has been stripped

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:

SSL has been STRIPPED and under attack - is lets encrypt not secure?

1 Like

Hi @logikal

your website has a valid Letsencrypt certificate - see - so that's not the problem.

Please explain. Every website is under attack, that's normal. It's a question of your webserver configuration, not of your certificate.

PS: Creating a screenshot has worked. May be share your screenshot.

1 Like

Hi @JuergenAuer

Thanks for your prompt reply.

I know for a fact that I am under attack from a developer in south Africa;. The client/bdauto - has decided to use them and ever since becoming aware of this - we have seen a number of botnets sending enormous amounts of traffic.

Now with no padlock (doesn't really mean much I suppose) but I have just enabled a wildcard (again not that secure I know) however It seems too much of a coincidence.

Could someone have tried to put a new SSL on this domain without my authorisation:?

1 Like

Re-enabled the wildcard*

1 Like

You can use to see all certificates issued to your domain.

It is possible, but unlikely, that hackers got into your machine or Cloud Account and replaced your certificate with something of theirs.

It is more likely your infrastructure experienced some issues under load that since resolved.

Check your system and account logins. Also ensure your SSL libraries are up to date.

1 Like

Thanks -

I use to check my libraries

Could a standard external domain certificate override an existing one - as it simply does not need authorising that you are the domain holder right

Since re-enabling the wildcard - I have no got the "pad" however on my CMS's. namely one of the CMS's is insecure under a particular admin but secure with another admin. Its very strange. I am currently doing a "better search replace" to see if there are issues.

1 Like

I don't see mixed content. And mixed content has nothing to do with your certificate.

The earlier check - - has already the wildcard.

Please explain: What's the exact url with the problem? Your main domain has no mixed content problem.

But if you use an admin interface with a different port, there are a lot of problems possible.

Again: Share a screenshot.

1 Like

From my endpoint, I'm getting a good HTTP to HTTPS redirect:

osiris@erazer ~ $ curl -LIv
*   Trying 2a07:7800::142:80...
*   Trying
* Connected to ( port 80 (#0)
> HEAD / HTTP/1.1
> Host:
> User-Agent: curl/7.74.0
> Accept: */*
* Mark bundle as not supporting multiuse
< HTTP/1.1 301 Moved Permanently
< date: Thu, 01 Apr 2021 18:06:43 GMT
< content-length: 0
< location:
< x-cdn-cache-status: MISS
< x-via: LHR2

So HTTPS isn't "stripped" due to a MitM attack which is removing HTTP to HTTPS redirects for example.

Further more, I see a normal Let's Encrypt certificate at HTTPS:

osiris@erazer ~ $ openssl s_client -connect  | openssl x509 -noout -text
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = *
verify return:1
        Version: 3 (0x2)
        Serial Number:
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Let's Encrypt, CN = R3
            Not Before: Mar 31 16:25:15 2021 GMT
            Not After : Jun 29 16:25:15 2021 GMT
        Subject: CN = *

And with a SHA256 fingerprint of:

osiris@erazer ~ $ openssl s_client -connect  | openssl x509 -noout -fingerprint -sha256
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = *
verify return:1
SHA256 Fingerprint=AB:E8:BA:65:8B:28:9F:A5:8C:78:80:32:77:76:89:C1:33:6B:D1:D6:5D:75:32:EF:AA:99:32:0D:5F:22:12:4E
osiris@erazer ~ $ 

You can verify this fingerprint with the fingerprint of the actual certificate on the server.

So if there is any MitM attack going on, it doesn't seem to be stripping anything or using a strange certificate.

1 Like

http to https ....

1 Like

Ah yes, HTTP to HTTPS, somehow the S has disappeared.

1 Like

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