Contact
Knowledgebase: General Questions
Frequently Asked Questions
Posted by Gareth S on 30 October 2012 09:10 AM

What is SSL? 

The SSL (and TLS) protocol stands for Secure Sockets Layer and is the Web standard for encrypting communications between users and websites, such as an e-commerce site. Data sent via an SSL connection is protected by encryption, a mechanism that prevents eavesdropping and tampering with any transmitted data. SSL provides businesses and consumers with the confidence that private data sent to a Web site, such as credit card numbers, is kept confidential. Web server certificates (also known as secure server certificates or SSL certificates) are required to initialize an SSL session.

Customers know a website is protected with an SSL certificate when their browser displays a little gold padlock and the address bar begins with an https:// rather than http://. Higher-end SSL certificates, known as EV (extended validation) certificates, are identified by a green address bar, which adds even more security and trust to a website. SSL certificates can be used on webservers for Internet security and mailservers such as IMAP, POP3, and SMTP for mail collection/sending security.

What is a RapidSSL Certificate? 

RapidSSL Certificates uniquely enable businesses to obtain low-cost, 1 year, fully functional single root trusted SSL certificates and are ideal for websites conducting low levels of e-commerce. Rapidsslonline.com owns the root used to issue the certificates, making RapidSSL both stable and far easier to install than a chained root install certificate.RapidSSL lowers the barrier of entry for companies that want single root SSL security by providing immediately issued certificates at the lowest cost available.

 

What is a RapidSSL Wildcard Certificate? 

RapidSSL Wildcard is a single root install SSL certificate that can be used to secure multiple sub-domains on a single domain name. RapidSSL Wildcard allows web sites to conduct secure e-commerce with an encrypted SSL connection and is ideal for low volume, low transaction value websites.

What is a Single Root SSL Certificate? 

When connecting to a webserver over SSL, the visitor's browser decides whether or not to trust the website's SSL certificate based on which Certification Authority (CA) has issued the actual SSL certificate. To determine this, the browser looks at its list of trusted issuing authorities - represented by a collection of Trusted Root CA certificates added into the browser by the browser vendor (such as Microsoft or Netscape).

Most SSL certificates are issued by CAs who own and use their own Trusted Root CA certificates, such as those issued by GeoTrust and RapidSSL.com. Because both GeoTrust and RapidSSL.com are known to browser vendors as trusted issuing authorities, their Trusted Root CA certificates have already been added to all popular browsers, and hence are already trusted. These SSL certificates are known as "single root" SSL certificates. For example, RapidSSL.com, a subsidiary of GeoTrust, owns the Equifax root used to issue its certificates.

What is a Chained Root SSL Certificate?

Some Certification Authorities do not have a Trusted Root CA certificate present in browsers, or do not use the root they own, and use a "chained root" in order for their SSL certificates to be trusted. Essentially, a CA with a Trusted Root CA certificate issues a "chained" certificate which "inherits" the browser recognition of the Trusted Root CA. These SSL certificates are known as "chained root" SSL certificates.

Installation of chained root certificates is more complex and some web servers and applications are not compatible with chained root certificates.

If a Certification Authority has and uses its own Trusted Root CA certificate that is already present in browsers,  this is a clear sign that the CA has been in the industry for a long-time, is stable, and credible, with long term relationships with many reputable browser vendors (such as Microsoft and Netscape). For this reason, such CAs are seen as being considerably more credible and trustworthy than chained root certificate providers who do not have a direct relationship with the browser vendors, or do not use their own root certificates to issue SSL certificates.

You can view the Certification Authorities who have and use their own root certificates by viewing the list in your browser. Chained root certificates require additional effort to install as the webserver must also have the chained root installed. This is not necessary for single root certificates.

Why is stability important for SSL certificates? 

The more stable an SSL certificate is, the more trust it can add to a website, which means customers are more likely to be comfortable conducting a transaction online. All of our SSL certificates are issued from a globally trusted CA root certificate such as Comodo or Symantec/VeriSign/Equifax/GeoTrust/etc. This means that all our certificates are stable.

What do you consider a low volume, low transaction website? 

As a general rule, we consider a low volume, low transaction website to be when typical customer transaction value is less that $50 USD per week, and volumes of transactions are less than 50 per week*.

If you have a low volume website and you decide that your customer's confidence is not affected at all by the brand behind the SSL certificate, then RapidSSL is the perfect answer.It is all about customer confidence. Whilst RapidSSL technology is production grade, only you can determine whether your customer’s confidence will improve significantly if you purchase a more established brand like GeoTrust.

*The 50 per week figure is simply a commercial guide and not a technical restriction. Technically speaking, the RapidSSL certificate will not be restricted from conducting more transactions than 50 - they are still industry standard 128 / 256 bit SSL certificates. However it is our professional opinion that sites conducting more than 50 transactions per week will require a Professional Level SSL certificate due to the increased likelihood that the website's customers will expect SSL from a highly credible and established SSL provider, along with a well-known, internationally accepted SSL brand.

What browser versions are compatible with RapidSSL, RapidSSL Wildcard? 

RapidSSL.com certificates are compatible with IE 5.01+, Netscape 4.7+, Mozilla 1+, AOL 5+, Firefox, Safari, and many other newer Windows- and Mac-based browsers. These certificates are all single root certificates (they do not use chaining technology), which means they are compatible with SSLv2 and SSLv3. Single root certificates are also more widely accepted by web servers, as some web servers do not accept chained root technology.Why are you providing RapidSSL and RapidSSL Wildcard secure server certificates? By providing RapidSSL and RapidSSL Wildcard certificates, we are lowering the barrier of entry for companies and websites wishing to secure their low volume, low value online transactions and data with the lowest cost single root install certificates available.

What is browser ubiquity or browser recognition? 

Browser ubiquity is the term used in the industry to describe the estimated percentage of Internet users that will inherently trust an SSL certificate. The lower the browser ubiquity, the less people will trust your certificate. If you are operating a commercial site, you would like as many people as possible to trust your SSL certificate. As a general rule, any SSL certificate with more than 95% browser ubiquity is acceptable for a commercial site.

Ubiquity is, however, not the only consideration in deciding whether one SSL certificate is better than another. Many companies running high-transaction, high-volume web sites need to maximize customer confidence and, therefore, purchase certificates from well-known, experienced security vendors who are all WebTrust compliant, like GeoTrust and Verisign.

If you have a low-volume website (less than 50 transactions per week) and you decide that your customers’ confidence is not affected at all by the brand behind the SSL certificate then RapidSSL or RapidSSL Wildcard certificates are the perfect solution.

Can I secure multiple subdomains with a single SSL Certificate? 

An SSL certificate is issued to a fully qualified domain name (FQDN). This means that an SSL certificate issued to "secure.rapidsslonline.com" cannot be used on different subdomains, such as "www.rapidsslonline.com". To get around this restriction, we have Wildcard Certificates available. Wildcard SSL Certificates allow you to secure multiple subdomains on the same domain name, thereby saving you both time and money. And, of course, you do not need to manage multiple certificates on the same server.

So with a single certificate issued to “.yourdomain.com,” you could protect:

  • www.yourdomain.com
  • secure.yourdomain.com
  • etc.yourdomain.com

For more details on our Wildcard SSL offerings, please click here. Or, please view Professional Level SSL Products for single root, highly credible Wildcard solutions.

Can I see which Certification Authorities have their own Trusted CA root present in browsers? 

Yes. Your browser contains a Trusted CA root certificate store. You can access this by opening Internet Explorer, going to Tools, selecting Internet Options, selecting the Content tab, clicking Certificates, and then selecting the Trusted Root Certification Authorities tab. You will then see a dialog box presenting a list of all Certification Authorities who own their own Trusted CA roots (you can examine the root certificate by double clicking it): 

GeoTrust owns the Equifax root (Equifax Digital Certificate services became GeoTrust in 2001).

How does a server certificate work? 

The end-user's browser requests a secure channel (via "https:") from the server, and then - if the server has an SSL certificate - the browser and the server negotiate their highest common encryption strength (e.g., 128-bits), and then exchange the corresponding encryption keys (this exchange is normally done using 1024-bit encryption strength). The 128-bit encryption key is then used for this particular instance of SSL, for all from-to exchanges between the browser and the server. The next https session will have a new session key.

The certificate guarantees the security of the connection between the browser and the server. Once data is in the server, it is up to the server admin to make sure the data remains protected.

 

What are AS1 and AS2 standards? 

AS2 (Applicability Statement 2) is a specification for Electronic Data Interchange (EDI) between businesses using the Internet's Web page protocol, the Hypertext Transfer Protocol (HTTP). The specification is an extension of the earlier version, AS1 (Applicability Statement 1). Both specifications were created by EDI over the Internet (EDIINT), a working group of the Internet Engineering Task Force (IETF) that develops secure and reliable business communications standards.

The AS2 standard provides Secure Multi-Purpose Internet Mail Extensions (S/MIME) and uses HTTP or a more secure version, HTTPS, to transmit data over the Internet. AS1 uses a slower protocol, SMTP (Simple Mail Transfer Protocol). The use of HTTP or HTTPS allows communication in real-time rather than through email delivery. Security, authentication, message integrity, and privacy are assured by the use of encryption and digital signatures. Another important feature, no repudiation, makes it impossible for the intended recipient of a message to deny having received it.

The AS2 standard allows businesses to use a common, single communications solution. This eliminates the complications and costs involved when different businesses in a network use different transfer protocols. A Web server, an EDI transfer engine, and digital certificates are required for data exchange using AS2. Almost any type of data can be transmitted.AS1 is based on IETF RFC 3335 and AS2 is based on RFC 1767.

What is the encryption strength of GeoTrust certificates? 

All GeoTrust certificates are 128-bit. During each and every session, the server and browser negotiate and choose the highest common encryption strength between them. So, if a 40-bit browser user hits your SSL-secured site, the resulting connection will automatically become a 40-bit strength encryption.

GeoTrust recommends that end-user Subscribers select the 1024-bit encryption strength or the equivalent descriptor option when generating their certificate requests. When the certificate's key length is 1024 or longer, the SSL session key will be 128 bit. If the certificate key length is 512, the SSL session key will be 40 bit or 56 bit.

If you are running Windows, see Microsoft's bulletin Q300398: "You install a 128-bit high encryption certificate onto Internet Information Server (IIS) version 4.0 or 5.0, then browse with a 128-bit enabled Web browser to IIS by using https://. However, the Web browser only makes a 40-bit or 56-bit Secure Sockets Layer (SSL) session with IIS (size 7927 bytes, updated 6/13/2001 12:54:00 PM GMT)."

How do I check if a 128-bit encryption is being used? 

Click here for a Secured by RapidSSL test page

- For Microsoft Internet Explorer
Move the mouse over the "security lock icon" at the bottom-right corner of the screen. A tool-tip of "SSL secured (128-bit)" should pop-up or you can just right-click any text on a page (not on a graphics object) and select "Properties." "Connection" with "SSL 3.0, RC4 with 128-bit encryption (High); RSA with 1024-bit exchange" is shown or Press "File" in the toolbar and select "Properties." "Connection" with "SSL 3.0, RC4 with 128-bit encryption (High); RSA with 1024-bit exchange" is shown.

- For Netscape Navigator

"Security" with "This is a secure document that uses a high-grade encryption key for U.S. domestic use only (RC4, 128-bit)" is displayed if you press "Security" in the toolbar. Then, a "Security Info" window will be displayed. Click "open page info" or right-click any text on a page (not on a graphic object) and select "View Info".

A Step by Step Guide to Receiving your Certificate: 

We and our CA partners employ a two-level automated vetting process. You must complete both stages of the vetting process before your SSL certificate can be issued from a CA.

Stage 1: Telephone Authentication

As part of the enrollment process, you will be prompted to complete the Telephone Authentication. This is where we will place an automated call to your telephone number and ask you to enter a PIN that we display on screen, so make sure you have access to a telephone when you enroll.

If you do not have access to a telephone or experience any difficulty in completing the Telephone Authentication during enrollment, do not worry. We will also send you an email specifying how you can attempt the process again, if needed. If you still have problems, please call our support team at 727-388-4240 or send us an email at support@rapidsslonline.com and we will assist you in completing the process manually.

Stage 2: Approver Email

When you have successfully completed the Telephone Authentication, we will send an Approver email to the designated APPROVER email address. You would have selected the Approver email address during enrollment. This would either be:

  • The email address associated with your WHOIS contact (if you are unsure, you can check this address by searching the WHOIS database at www.nic.com)
  • A generic email address such as
    • administrator@yourdomain.com 
    • webmaster@yourdomain.como
    • admin@yourdomain.com
    • ssladmin@yourdomain.com
    • root@yourdomain.com
    • hostmaster@yourdomain.com
    • postmaster@yourdomain.com

 

Unless the Approver receives this email and approves the application by clicking on the link within the email, your certificate cannot be issued. If you are the administrator of the Approver email address, please check any spam filters and virus protection folders in case the email has been quarantined.

We strongly recommend whitelisting the email addresses below if you are using a SPAM filter.

For the CAs:

RapidSSL

  1. support@rapidssl.com
  2. sslorders@rapidssl.com


GeoTrust

  1. support@geotrust.com
  2. sslorders@geotrust.com

Thawte

  1. support@thawte.com
  2. sslorders@thawte.com

Symantec

  1. support@symantec.com
  2. sslorders@symantec.com

Trustwave

  1. support@trustwave.com
  2. sslorders@trustwave.com

Comodo

  1. support@comodo.com
  2. sslorders@comodo.com

For the SSL provider:

  1. sales@[domain name].com
  2. support@[domain name].com
(0 vote(s))
This article was helpful
This article was not helpful

Comments (0)
Post a new comment
 
 
Full Name:
Email:
Leave Your Feedback:
CAPTCHA Verification 
 
Please enter the text you see in the image into the textbox below. This is required to prevent automated registrations and form submissions.

© 2012 SSLHelpdesk.com All rights reserved • Privacy PolicyTerms of Service