Any online organization that hosts a single domain name with multiple subdomains can meet all of its SSL encryption needs without the hassle and financial commitment of procuring and maintaining multiple SSL certificates to secure multiple subdomains. Wildcard SSL certificate is a cost-effective and efficient means of securing all subdomains like microsites without managing multiple certificates. All the features, compatibility and warranty of our PremiumSSL Certificate are included. Wildcard certificate comes with unlimited server licensing included in the price – meaning you are free to install it on as many physical servers as you wish.

Any wildcard certificate for *.exampledomain.com will secure www.exampledomain.com, mail.exampledomain.com, and any other subdomain of exampledomain.com. Wildcard stands out by allowing you to secure all subdomain of the domain your certificate was issued to through the use of Subject Alternate Names, or even the base domain itself —exampledomain.com— something no other wildcard currently offers. Wildcard is a smart investment that saves you the time and overhead of managing multiple certificates and expiration dates.

Wildcard SSL Certificates secure websites the same as a regular SSL certificate, and requests are processed using the same validation methods. However, some Web servers might require a unique IP address for each subdomain on the Wildcard certificate.

Security: If one server or sub-domain is compromised, all sub-domains may be compromised. Management: If the wildcard certificate needs to be revoked, all sub-domains will need a new certificate.Compatibility: Wildcard certificates may not work seamlessly with older server-client configurations. Protection: VeriSign Wildcard SSL Certificates are not protected by NetSure extended warranty.

99+% Browser Recognition

Secure Sockets Layer (SSL) is a security protocol that requires a web server and browser to work together to establish an encrypted channel for the exchange of information. Seamless trust between a browser and server depends on the browser’s ability to trust the SSL provider.

When Servers and Browsers Connect

• When a web browser attempts to connect to a server secured with SSL, the browser requests identification.
• The server sends the browser a copy of its SSL certificate.
• The browser checks whether it trusts the SSL certificate. If so, it sends a message to the server.
• The server sends back a digitally signed acknowledgement to start an SSL encrypted session.
• Encrypted data is shared between the browser and the server.

Trusting the SSL Certificate

Browsers determine whether or not to trust an SSL certificate by checking the source of the certificate issuance. If the SSL certificate is issued by a Certificate Authority that is known and trusted by the browser, the browser extends that trust to the web site secured by the SSL certificate. If the certificate is self-signed or issued by an unknown Certificate Authority, the browser may display an alert or security warning.

Root Certificate Ubiquity

Most browser vendors release their software with pre-installed root certificates from known Certificate Authorities. An SSL certificate’s root ubiquity or level of browser recognition (also called browser compatibility) reflects the number of browsers that trust the Certificate Authority. There may be a few older or uncommon browsers missing root certificates. This is why SSL providers do not claim 100% browser compatibility.

These are the server software that accept the wildcard characters in the common name:

• Apache-ModSSL
• Cisco CSS 11500
• F5 FirePassiPlanet
• Java Web Server
• Lotus Domino
• Microsoft IIS 5.x and later
• Microsoft IIS 6.x
• Microsoft IIS 7.x
• Microsoft ISA
• Novell Web Server
• RedHat Linux
• Tomcat
• WebSTAR 4.0 and later
• Zeus Web Server
• Plesk