How does shared SSL work?
In order to understand how shared secure certificates work we need to understand a few basic SSL characteristics.
Standard SSL certificates are created to function with one unique fully qualified domain name (FQDN). This is the base domain name plus any prefix (sub domain). The standard SSL certificate needs to be addressed at this specific FQDN or it will produce errors messages.
Table A - Standard SSL Access (ourshop.org ficticious hosting company)
| Certificate's FQDN | Valid URL | Invalid URL **
valid with wild-card certificates |
The URLs listed in the "invalid" column are valid when using a wild card certificate created for the root domain name. Web site owners that want their own SSL certificate will usually get a standard (single FQDN) certificate. |
|
| www.ourshop.org | https://www.ourshop.org | https://ourshop.org |
| | https://abc.ourshop.org |
|
| ourshop.org | https://ourshop.org | https://www.ourshop.org |
| | https://abc.ourshop.org |
|
| abc.ourshop.org | https://abc.ourshop.org | https://ourshop.org |
| | https://www.ourshop.org |
Table "A" shows how in a standard SSL situation, a secure certificate is only valid with the complete domain portion of the web address. A Wild Card Certificate however, allows access from any subdomain. ** Each of the URLS in the "invalid url" column are valid with a wild card certificate for "ourshop.org". Purchasing a wild card certificates is usually much more expensive than a standard certificate.
Shared SSL usually takes one of the following forms:
- Wild card certificate pointing at the customer's document root
- In this case the user is assigned a subdomain (usually the same as their web hosting user name) which combines with the wild card certificate name to point at their web hosting account document root directory.
- "https://yourusername.ourshop.org" and the non-secure "http://www.yourdomain.com" point to the same home page.
- See Table A however "Invalid URLs" would be Valid
- Standard certificate with a user directory path.
- This method typically points to a separate directory where you can upload the pages you want to be secured.
- See Table B
- Standard certificate accessible from the hosting companies available package shopping cart.
- This method typically allows the shopping cart provided by the hosting company to secure orders using either a wild card or standard certificate. This is a variation of 1 and 2 (above) but the shared certificate is only usable from within the provided shopping carts.
Note: in each of these situations the URL that is being used during secure processing combines some type of user identifier along with one of the hosting company's domain names. A web site hosting company's particular shared ssl method may be a variation of the above. You should ask what form of shared ssl your prospective host is using before you sign up. The advantage in the first type of shared ssl using the wild card certificate is that you have more flexibility.
Table B - Shared SSL using a standard NON Wild card Certificate
| Certificate's FQDN | Customer Username | Secure URL |
|
| www.ourshop.org | abcdef | https://www.ourshop-secure.com/abcdef/ |
|
| www.ourshop.org | xyz | https://www.ourshop-secure.com/xyz/ |
Table "B" shows the shared secure certificate method using a single FQDN certificate. In this example we used a seperate domain name to handle shared secure processing though this is not always the case. We could have used a sub-domain such as "https://secure.ourshop.org/abcdef/" instead. The "path" method of shared SSL using a standard single domain certificate is not our prefered method. We like to see shared SSL using wild card certificates that point to the customer's main document directory. The wild-card method (number "1" above) allows us greater flexibility and the URL looks a bit more professional.
There are a number of variations on these examples. In practice, most hosting companies that offer shared secure certificates use some form of what we've shown here.
