After disabling CDN, problems with SSL

Started by Alex, Sep 21, 2022, 01:11 AM

Previous topic - Next topic

AlexTopic starter

The problem is that:
There is a site sitting on the domain. There is S3 storage where massive static media files for this website are stored.
Physically, the server on which the site and the server on which the storage are different. On the domain where the website is, a subdomain is allocated that looks at S3 storage (via DNS CNAME record).

In the past, the subdomain looked at the storage via CDN (the DNS CNAME indicated the addresses of the CDN used) and everything worked.
The site uses SSL Wildcard, in the CDN settings it was also indicated that https is needed.
And as a result, I had access to my files at https:// subdomain. domain /file

Not so long ago, the CDN I used lost its free tariff (provided that it is used only on top of their own storage, which was just my case), and the cheapest of the remaining ones did not suit me very much in price. generally, there is no CDN now and you need to configure the subdomain to look directly at the storage. And then the actual problem appeared.

Files are available at the following addresses:
https:// storage server_address /files
http: // subdomain. domain /files
But not available by
https:// subdomain. domain /files

https is valid on the storage itself.
When accessing the same files via a subdomain, a certificate error occurs.
In addition to the existing SSL Wildcard on the main domain, I ordered and installed the usual SSL on the subdomain - this did not affect in any way.
The nslookup command for the subdomain issues the storage server as a Non-authoritative answer.

What should I do to make https work again when accessing files through a subdomain looking at the repository?

UPD. Now I decided on whois check the info on your subdomain. And I was a little freaked out, because I was given that the domain is free. The domain check gave out the correct information.
How is that even possible?
There was a thought that I had picked something wrong in DNS, and it opens over http normally like a cache. But another browser displayed the subdomain just as well. domain /files.
Checking a subdomain in whois with your registrar ( /whois/) gave out that it was not possible to check (well, at least I did not say that I was free).
This situation is a big deal and it needs to be dealt with, or is it normal for subdomains?


How was it installed? It is enough to install (and activate) a certificate and a private key on the storage web server.
The question is 11 years old, so I can't vouch for the relevance of the decision:

What makes you think that WHOIS information should be returned for a subdomain? Do you have a well-known WHOIS web server?
There are 3rd-level domains with a full-fledged zone, including a WHOIS server, but that clearly does not apply to yours.


it can be caused by several reasons:

The site does not use SSL, but it shares an IP address with another site that uses SSL.
The site no longer exists, but the domain still points to the old IP address, which now hosts another site.
The site uses a content delivery network (CDN) that does not support SSL.
The domain name alias was not included in the certificate.