What type of custom domain SSL certificate is best for my organization's needs?
Sites that use custom domain SSL
Oracle B2C Service (OSvC), All supported versions
We are interested in setting up a custom domain for our site and will need SSL coverage, but are unsure which certificate type would be best for us.
There are a few different SSL certificate types available for purchase by you from a Certificate Authority outside of Oracle, each with its own benefits. In general, it is in your organization's best interest to try to cover as many B2C Service domains as possible within the smallest number of certificates. You should work with your IT staff on what your needs are in this regard.
This is encouraged because your B2C Service account is billed per unique certificate that is hosted in our server environment, and because managing SSL certificates for multiple interfaces simultaneously can be challenging if there are several certificates involved.
The most common certificates used for Oracle B2C Service are single-domain, SAN (Subject Alternative Name) and wildcard certificates. Descriptions for each type are below:
Single-domain: As its name implies, this certificate type covers only one domain. This could be appropriate for B2C Service sites where only one interface address will need to be covered, and there is no plan for future growth expected.
Subject Alternative Name (SAN): This certificate type is the most common for B2C Service sites. It allows for a single common name as well as multiple Subject Alternative Names that can also be covered on the same certificate. Every Certificate Authority is unique in its policy, however typically SAN certificates can cover many domains at a time, with upper limits ranging anywhere from 40 to 100.
Wildcard: This certificate type allows for an unlimited number of domains to be covered, however it is critical to note that the wildcard value applies only to one sub-level of domain. For example, if you buy a wildcard certificate for *.help.examplesite.com, the sites you are planning to cover must have naming conventions that have a single, continuous string in place of the wildcard asterisk, like so:
Notice in the above examples that a dash is used as a logical separation to allow a continuous string. You could not add an additional dot, because this would section off a new portion of sub-level and break the formatting rules for a wildcard cert.