[thelist] eCommerce / Secure Cert / domain path question

Bill Moseley moseley at hank.org
Sun Jul 18 15:30:32 CDT 2010


On Sun, Jul 18, 2010 at 8:12 AM, Bob Meetin <bobm at dottedi.biz> wrote:

>
> We purchase a certificate for www.abc.com, so
>
> www.abc.com
> www.abc.com/service1
> www.abc.com/service2
> are covered, but not:
>
> http://www.abc.com
> http://www.abc.com/service1
> http://www.abc.com/service2


http:// is not SSL, so I'm not clear what you are asking.  And the path part
is not important as certificates are issued for domains, not paths.

Hopefully Brian can explain the multiple domain certificates, but from what
you posted so far I suspect what you want is a single-domain certificate for
www.abc.com (or www.example.com might be a better example).

I have little understanding of this, so I'm hoping someone will correct and
enlighten.

Certificates store the host name in the Common Name (CN) field (but see
below).  The client (browser) compares the requested domain name with the CN
returned in the certificate.

SSL negotiation happens before the HTTP request is sent -- obviously because
otherwise it would not be a secure request.  This is/was a problem with
virtual hosting where multiple domain names where handled by the same IP &
port.  Since the host selection is done via the HTTP Host header with
virtual hosting there was no way for the web server to know what domain was
being requested and therefore no way to send different certificates based on
the requested host.

The fix for this was Server Name Indication (SNI) where the clients sends
the requested host name in the initial SSL handshake.  This allows the web
server to select the correct certificate for the requested domain to be sent
to the client.  I'm assume that's well supported now.

Another approach is using the Subject Alternative Name extension of the
certificate -- which is an extension of the certificate protocol allowing
multiple domains in a single certificate in addition to the CN field.  As I
demonstrated, I don't know much about these because we don't use them.
 Maybe it's because they have to be reissued when you want to add a name?

Brian, can you explain how the non-SNA multiple domain certificates work?


If we set up redirection in the .htaccess so that:
>
> abc.com
> www.abc.com
> etc.
> are all redirected to http://www.abc.com, will that cover the problem?
>  Otherwise, would the GlobalSign handle this? This is just a bit confusing.
>

I suspect you don't want to redirect www.abc.com to back to www.abc.com.
 Anyway, I think for small sites a common approach would make
http://abc.com/ redirect to http://www.abc.com/.  Then when you want to use
SSL you redirect to https://www.abc.com/   If you have a cert for
www.abc.com then if someone goes to https://abc.com/ they will get a
certificate error.


> Another option I hadn't considered would be to set up a single master
> payment type website so that all payments get redirected.
>

Like Paypal?  Not a bad idea to let someone else worry about SSL, PCI DSS,
payments, etc.



-- 
Bill Moseley
moseley at hank.org


More information about the thelist mailing list