I'm stuck

OS: CentOS 7:
Whenever I set a webserver up I always redirect the ... to ... thus without the 'www'. Just because I think those letters are totally useless.

Now I'm trying to install a webserver with SSL added using http://letsencrypt.org (see, no www )
It works 'locally' thus on the server itself using 'curl';

but with I get this error:
I also get some errors in external browsers like Firefox in windows with them all, some tells me it ain't a secure connection others tells me 'the page isn't redirecting properly'.

and YES, I've used google, I might even overloaded it at some point

PS, making an update as I post this to get the latest, just in case, but I doubt it.

What have I missed?


UPDATE: You need to ask what you need to see 'cos I have no idea it can be

Does the cert not cover www.sitename?

Have you redirected https://www.sitename to https://sitename?
The redirect should kick in before the cert is checked. (I think)

If you drill down (click on the padlock) in Firefox you should be able to see the specifics of the mis-match.

1 members found this post helpful.

Your cert will have to include both forms, www and non-www.

You can include both in a LetsEncrypt cert by something like this in the CSR (signing request):

It doesn't matter that there is a redirect, the https://www.whatever request itself must be secure in itself, and obviously it is not.

If you still have problems after getting the dual named cert, it would be helpful if you could post the server directive that you are using to perform the redirect, and tell us where you do that (i.e. in the vhost config, in the main server config, or in a .htaccess).

2 members found this post helpful.

My mis-understanding. I am redirecting example.net to https://example.com successfully, but an attempt to go to https://example.net results in a cert warning, even when coding a redirect for example.net in the ssl.conf. So, I was mistaken, and as astrogeek points out, an https call requires that the domain being called have its own cert.

So, #2 was wrong. Sorry...but fun to learn

2 members found this post helpful.

Easy mistake to make.

Think of it this way: The redirect is the response to the https://www.whatever request. The request was via secure protocol, so the response, be it redrect, error or data, must be via secure protocol as well. If for any reason that is not possible, then the user must be made aware that it is not secure - any other behavior would make the protocol untrustworthy!

1 members found this post helpful.

Yep, that worked, had to cert both www and @
thx guys