Why would leaving www from a URL affect the routing and certificate validity

purplesoup
purplesoup used Ask the Experts™
on
Entering http://www.felixstowerotaryclub.org correctly routes to the correct website and sets up a secure connection.

Entering http://felixstowerotaryclub.org routes back to the old website.

Entering https://www.felixstowerotaryclub.org connects correctly

Entering https://felixstowerotaryclub.org gives an invalid certificate error.

How can I get http://felixstowerotaryclub.org to route to the new website and https://felixstowerotaryclub.org to not give an invalid certificate error?
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Scott FellDeveloper & EE Moderator
Fellow 2018
Most Valuable Expert 2013

Commented:
Your best option is to use only the www and instead redirect the naked domain to www.  This would be true with or without using a cert for seo reasons.
purplesoupProgrammer

Author

Commented:
I wouldn't say it was the best option to force people to have to enter "www" - it seems pretty common nowadays for people to not have to always add it in - how would it normally work to make it optional?
Software Engineer
Distinguished Expert 2018
Commented:
You need a certificate that has a Subject Alternative Name (SAN) for the non-www case.
so the certificate needs to be valid vor www.felixstowerotaryclub.org AND felixstowerotaryclub.org.

This is a SSL validation check done in curl...
$ curl -v https://felixstowerotaryclub.org
*   Trying 184.168.131.241:443...
* TCP_NODELAY set
* Connected to felixstowerotaryclub.org (184.168.131.241) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: jurisdictionC=US; jurisdictionST=Arizona; businessCategory=Private Organization; serialNumber=R17247303; C=US; ST=Arizona; L=Scottsdale; O=Special Domain Services, LLC; CN=shortener.secureserver.net
*  start date: Sep 26 22:40:51 2018 GMT
*  expire date: Sep 26 22:40:51 2020 GMT
*  subjectAltName does not match felixstowerotaryclub.org
* SSL: no alternative certificate subject name matches target host name 'felixstowerotaryclub.org'
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, close notify (256):
curl: (60) SSL: no alternative certificate subject name matches target host name 'felixstowerotaryclub.org'
More details here: https://curl.haxx.se/docs/sslcerts.html

Open in new window


$ curl -v https://www.felixstowerotaryclub.org
*   Trying 35.172.94.1:443...
* TCP_NODELAY set
* Connected to www.felixstowerotaryclub.org (35.172.94.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=www.felixstowerotaryclub.org
*  start date: Aug  3 08:38:34 2019 GMT
*  expire date: Nov  1 08:38:34 2019 GMT
*  subjectAltName: host "www.felixstowerotaryclub.org" matched cert's "www.felixstowerotaryclub.org"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55f348b7f6a0)
> GET / HTTP/2
> Host: www.felixstowerotaryclub.org
> User-Agent: curl/7.65.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 200
< server: nginx
< date: Tue, 01 Oct 2019 15:43:28 GMT
< content-type: text/html;charset=utf-8
< cache-control: no-cache, no-store, must-revalidate
< expires: Thu, 01 Jan 1970 00:00:00 GMT
< strict-transport-security: max-age=604800
< vary: Accept-Encoding
< vary: User-Agent,Accept-Encoding,Accept-Encoding
< x-content-type-options: nosniff
< x-xss-protection: 1; mode=block
<
<!doctype html >
<html xmlns="http://www.w3.org/1999/xhtml"  class="">
<head>

Open in new window


Also they point to different servers those thould be the same (using a CNAME f.e.)
$ dig www.felixstowerotaryclub.org

; <<>> DiG 9.14.4 <<>> www.felixstowerotaryclub.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20307
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 2f6f91c670c108537f992f7e5d937485c37566ada7340c34 (good)
;; QUESTION SECTION:
;www.felixstowerotaryclub.org.  IN      A

;; ANSWER SECTION:
www.felixstowerotaryclub.org. 3499 IN   CNAME   s.multiscreensite.com.
s.multiscreensite.com.  60      IN      A       100.24.208.97
s.multiscreensite.com.  60      IN      A       35.172.94.1

;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Oct 01 17:45:09 CEST 2019

Open in new window


$ dig felixstowerotaryclub.org

; <<>> DiG 9.14.4 <<>> felixstowerotaryclub.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28624
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 69fbf6858e20512ac79e7bd15d93748aa3ff86f3ac136265 (good)
;; QUESTION SECTION:
;felixstowerotaryclub.org.      IN      A

;; ANSWER SECTION:
felixstowerotaryclub.org. 299   IN      A       184.168.131.241

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Oct 01 17:45:14 CEST 2019
;; MSG SIZE  rcvd: 97

Open in new window

11/26 Forrester Webinar: Savings for Enterprise

How can your organization benefit from savings just by replacing your legacy backup solutions with Acronis' #CyberProtection? Join Forrester's Joe Branca and Ryan Davis from Acronis live as they explain how you can too.

David FavorFractional CTO
Distinguished Expert 2018
Commented:
You said, "Why would leaving www from a URL affect the routing and certificate validity".

Your question covers many technologies, which can be complex to work through.

1) DNS - as noci mentions, currently your DNS will fail in all manner of ways.

Best practice for DNS is for your lookups to look like this...

imac> dig davidfavor.com | paragrep "ANSWER SECTION"
==== -
;; ANSWER SECTION:
davidfavor.com.		264	IN	A	144.217.145.114

imac> dig www.davidfavor.com | paragrep "ANSWER SECTION"
==== -
;; ANSWER SECTION:
www.davidfavor.com.	274	IN	CNAME	davidfavor.com.
davidfavor.com.		274	IN	A	144.217.145.114

Open in new window


The way your DNS is setup will cause complex SSL/TLS breakage.

2) HTTPS

Best practice for HTTPS is to setup these redirects.

Note: Do not under any circumstance use a 301 rather than a 302. Ever. As 301s cache at the browser level + if you make a mistake with a 301 setup, any visit while the 301 mistake is active, will cache at the browser. Also because of browser caching if you use 301s + change the target of the 301, you can end up with old visitors landing in many random pages. 301s are the bane of redirects.

Setup... See Scott's comment above about SEO.

https://felixstowerotaryclub.org - terminal request which returns a 200 + content
https://www.felixstowerotaryclub.org - returns 302 -> https://felixstowerotaryclub.org
http://felixstowerotaryclub.org - returns 302 -> https://felixstowerotaryclub.org
http://www.felixstowerotaryclub.org - returns 302 -> https://felixstowerotaryclub.org

Open in new window


3) TLS (SSL)

You'll generate certs to cover each property.

Might be a wildcard cert covering *.felixstowerotaryclub.org or a UCC cert covering felixstowerotaryclub.org + www.felixstowerotaryclub.org to mention 2x common approaches.

How you do this is completely dependent on how you choose to generate your certs.

I use https://LetsEncrypt.org certs because I can do a one time setup + a CRON job to auto renew each cert, so LetsEncrypt certs are setup + forget, which is how I like my certs.
David FavorFractional CTO
Distinguished Expert 2018

Commented:
Suggestion: Might be useful for you to hire someone for an hour or two, to go through your entire setup to work through all details, so you have a rock solid starting point.
purplesoupProgrammer

Author

Commented:
Thanks I'm sure that's enough to get me sorted! Much appreciated.
David FavorFractional CTO
Distinguished Expert 2018

Commented:
You're welcome!

Glad you have clues toward a resolution!
Scott FellDeveloper & EE Moderator
Fellow 2018
Most Valuable Expert 2013

Commented:
I wouldn't say it was the best option to force people to have to enter "www" -
Your right, it is not. On your server the proper thing to do is set up a redirect as David points out. If somebody surfs (actually 'Cerfs') to the naked domain, you will set up a redirect to the 'www'.  That way no matter if they go to the naked domain or www, they end up at the www where you have a certificate.  

I use wildcard domains but that is for using sub domains such as dev.mydomain.com along with www.mydomain.com. For live content, I always redirect to either the www or naked, typically the www but not allow both.

I hope that makes sense.
purplesoupProgrammer

Author

Commented:
Yes sorry Scott I misunderstood your original comment - your suggestion does sound very sensible.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial