It all starts with something called a root certificate. The root certificate is generated by a certification authority (CA) and is embedded into software applications. You will find root certificates in Microsoft Windows, Mozilla Firefox, Mac OS X, Adobe Reader, etc. The purpose of the root certificate is to establish a digital chain of trust. The root is the trust anchor.

The presumption is that the application developer has pre-screened the CA, ensured it meets a minimum level of trust and has accepted the CA’s root certificate for use. Many application developers, including Adobe, Apple, Mozilla, Microsoft, Opera and Oracle, have root certificate programs. Others rely on the roots provided by the underlying operating system or developer toolkit.

One of the main functions of the root is to issue chain certificates to issuing CAs — the first link in the chain of trust. Your Web browser will inherently trust all certificates that have been signed by any root that has been embedded in the browser itself or in an operating system on which it relies.

Why do you need an issuing CA? The purpose of the issuing CA is to isolate certificate policy from the root. Issuing CAs can be used to issue many different certificate types: SSL, EV SSL, Code Signing, Secure Email, Adobe CDS, etc. These certificate types are subjected to different requirements and risks, and as such have different certificate policies. The certificates may have different assurance levels such as high, medium and low. Issuing CAs may also be controlled by an organization other than that which controls the root.

The last link of trust is that between the end entity certificate and the issuing CA. In the case of an SSL certificate, the end entity certificate represents the linkage between a website owner and the website domain name. The SSL certificate is installed on the Web server along with the chain certificate. When a user browses to the website protected by the SSL certificate, the browser initiates the verification of the certificate and follows the chain of trust back to the embedded root.

In some cases, the CA may have chosen to issue end entity certificates directly from the root CA. This is an outdated practice; issuing directly from the root increases risk and limits how certificate policy can be managed and enforced. Issuing directly from the root can also impact performance as the browser may have to verify a large certificate revocation list (CRL) during its chain validating process. Major public CAs are discontinuing or limiting this practice.

When you receive an Entrust certificate, we provide any required chain certificate complete with installation instructions.

Why is this significant to our customers? Back in 2007, with Microsoft adding new features such as AutoDiscovery to Exchange Server, the number of services each server needed to protect with SSL encryption started increasing.
As a result, Exchange Server 2007 outgrew traditional SSL certificates and required a new certificate that supported multiple names. This led to the introduction of Unified Communications (UC) certificates several years ago, which typically had a fixed number of domains (SANs) they could support, based on the number of services anticipated to be used in Unified Communications.

Since then, however, we’ve seen the need for this product dramatically increase. Customers were not only using these certificates for Unified Communications purposes, but for many other uses as well, such as virtual hosting over SSL on a single IP address. For example, if you have a website www.example.com, but it is also known as example.com and www.example.net, then a multi-domain certificate with all domain names listed in the Subject Alternative Name (SAN) field is what you need.

And of course, since UC certificates were organizational validated, and many customers are looking for even stronger security to represent their corporate brand, we’ve seen the demand for multi-domain support increase for Extended Validation (EV) certificates as well. This holds particularly true in the banking sector, where consumers are understandably hypersensitive about verifying with whom they are transacting.

And now, Entrust offers both Extended Validation (EV Multi-domain) and Organizational Validation (UC Multi-domain) certificates with multi-domain support built-in.

Both certificate types can be purchased online or in a Certificate Management Services (CMS) account. When creating a new certificate, users simply paste their CSR into a field that parses any Domains (SANs) included in the CSR, and are then presented with an option to add additional domains — up to 50 for online single certificate buyers, and up to approximately 150 for CMS customers, provided they have available inventory.

Domains (or SANs) can be either fully qualified domain names (e.g., www.entrust.net) or unique IP addresses (e.g., 216.191.247.140) — in either case the uniqueness of the address is important to ensure maximum security.

If you’re looking for a multi-domain or multi-SAN certificate, visit us at http://www.entrust.net and we’ll be happy to serve your SSL needs.

Internet SSL Survey 2010 by Ivan Ristic
In this study, Qualys SSL Labs searched large numbers of internet domain names for HTTPS servers and used their assessment engine to collect statistics about SSL usage.  In total, they found 867,361 unique certificate chains offered by HTTPS servers.  By their estimate, this accounts for 25-50% of all commercial certificates.  Issues found were incomplete certificate chains, chains that are too long, certificates presented in the wrong order, and certificates with Debian weak keys.

HTTPS Can Byte Me by Robert Hansen and Josh Sokol
This presentation was about the flaws in the browser implementation of HTTPS or rather flaws that can be exploited even when the user is connecting to a site over HTTPS. The researchers focused on 24 issues all related to man-in-the-middle (MitM) attacks. They concluded that some of the attacks were hard or flakey and that there are better ways to exploit people and learn their vital information. In Hansen and Sokol’s associated white paper, they state: “Using proper tab isolation, better cookie management in the browser and better ‘white-noise’ generation in the SSL stream could help prevent the majority of these attacks presented.”

An Observatory for the SSLiverse by Peter Eckersley and Jesse Burns
Electronic Frontier Foundation (EFF) SSL Observatory collected x.509 Certificates used for HTTPS on the internet. They looked for odd behavior and were basically checking up on CAs. They were able to identify “trusted” intermediaries (foreign, security agencies, companies) and found many “weird, wonderful and suspicious certificates.” They will be opening their data to the public for further review.

In particular, a feature we are quite proud of is our new automated full key backup. This enables customers to rest easy, because anything they encrypt with these certificates, regardless of how often they rollover their certificates, will always be accessible. If a user should lose their password, the administrator can simply re-issue the certificate. If a user should suspect their private key has become compromised, the administrator can simply revoke and then re-issue the certificate free of charge, and the user will receive a certificate package containing a new certificate and all the keys required to decrypt their historical data. Same thing when it comes time to renew the certificate…the new certificate will contain all the keys required to decrypt their historical data. The user is always able to maintain their ID, with a single password,  throughout the various normal but numerous events that typically occur.

From what we can tell, in the under-250 user range, our competitors don’t have any form of automated key backup, and recommend to their customers to backup their keys manually to a P12 certificate container, and place it in a secure location. While this does work, it is really not manageable for any reasonable number of users. Some users just won’t go through the process, and because it would require some coordination and backup of the P12’s, it can be costly and inefficient. Also, as time passes and more certificates rollover to new certificates, it becomes even worse to manage. Users end up having to remember passwords from multiple key pairs, or worse still, they don’t protect them with passwords at all, putting security at risk.

Like our other certificate services offerings, our Secure Email certificates are competitively priced, so please do check us out on our website come Tuesday or speak to one of our representatives!

I took a closer look at the Netcraft SSL Survey data. It found 334,777 GeoTrust certificates of which 304,199 were domain-only validated.  As VeriSign states, “the chief intended purpose of SSL is authenticating sites and protecting transactions”; however, 91% of the time GeoTrust SSL certificates fail to provide any identifying information with regards to who controls the web site.

Domain-only validated (DV) certificates are typically verified and issued through automated processes. Human intervention is minimized and organization checks are eliminated to support issuing the certificates quickly and cheap. As such, a DV certificate contains no identifying information in the organization name field. Typically this value just re-states the domain name or simply says “Persona Not Validated”. This means that although the certificate supports transaction encryption, the end user cannot confirm who is on the other end. So the transaction is encrypted for whom? 

Certificates verified using Organization validation (OV) or Extended validation (EV) practices contain the verified name of the entity that controls the web site. Certification Authorities issuing these certificates check with third parties to establish the official name of the organization and where they are located.  The CA takes further steps to contact the requesting organization to confirm that they did indeed request the certificate and that the requester is authorized to receive the certificate on behalf of the organization. When visiting a web site using an OV or an EV certificate, the end user can use the certificate to verify that they are sending their transaction data to the intended recipient.

At Entrust, 100% of our SSL certificates provide organization identity. All of our SSL certificates are intended to provide security, accountability, and trust.

 Lately, I’ve had many people ask me why they would use Adobe CDS signing certificates instead of one of many other methods to sign PDF documents…why not;

• Use a publicly trusted user certificate?
• Use a privately trusted user certificate?
• Use a certificate supported by the  Adobe Approved Trust List (AATL)

 So, for starters, I ask our customers what they are looking for….do you want people outside your organization (the general public) to trust the digital signature? If it’s just for internal users, and you don’t care about the visual indicator within the PDF format then perhaps privately trusted certificates are fine for signing your documents. But if you do want the public to trust the digital signature, then you need a publicly trusted certificate…but not just any publicly trusted certificate…you need one where the root certificate is embedded inside Adobe Acrobat or Adobe Reader. That way, the document recipient can trace the root of trust and know that the signature is valid and trusted.

 Now think about the dynamics of your recipient population….do your users all have Adobe Acrobat or Reader v9 or greater? If not, then you need to use Adobe CDS certificates, because the root of trust is embedded in Adobe all the way back to Adobe Acrobat and Reader v6. That means that upwards of 99% of your likely recipient population will be able to validate and trust the digital signature, and when it comes right down to what you want, it means that more people will trust and therefore read the material you intend for them.

 More flexibility, more trust, happier partners and customers!

 PS. By the way, Entrust sells Adobe CDS certificates for a variety of scenarios, from individual signing to organizational automated signing processes. See our web site

This bold statement and has alarmed many in the internet security community. Security provider Comodo got so excited, they issued a press release urging Mr. Ristic to “review these figures before publishing or presenting this to an informed audience.”  In his blog post, Mr. Ristic refuted the alleged quotes and stated “they’ve generally focused on the wrong aspect of the study and that, in fact, I made no such sensational claims.” He went on to clarify as follows:

The important number is the 720,000 certificates whose names do match the domain names on which they reside. For each of those, someone made an effort to match the names, and those are the servers that are worth investigating further.

Sadly, some people chose to focus on the numbers that help make an interesting headline, but which aren’t very interesting from the research point of view. The reason we have so many domain names that do not have proper SSL certificates installed is that most of them are not _intended_ to have them. Multiple domain names will point to the same IP address and, thus, to the same SSL server. (Remember, virtual SSL hosting is not yet mainstream.) The difference in numbers is because of the widespread use of virtual web hosting, which is available for non-SSL sites, but not yet for SSL sites. You can host a million plain-text web sites on a single IP address, but if you want a million secure sites, you’d need a million IP addresses.

We in the SSL industry are getting used to the Black Hat and DEF CON excitement at this time of year.  The last two years have provided SSL security “revelations” from respected researchers Dan Kaminsky, Michael Zusman, and Moxie Marlinspike. This year should be no exception with talks from Ivan Ristic at Black Hat 2010 and from Peter Eckersley at DEF CON 18.

At Entrust, we look forward to the silly season.  The security experts draw their line in the sand, throw down the gauntlet, and we as security providers must review and respond.  It keeps us sharp.  Its healthy.  As such, we’ll keep an eye on the goings on at Black Hat and DEF CON and will respond accordingly.

The US National Institute of Standards and Technology (NIST) prepared a special report SP 800-57 in 2005 for comment.  The updated report SP 800-57 in March 2007 Part 1 and subsequent reports Part 2 and Part 3, laid the foundation for how application developers and certification authorities would manage key sizes for digital certificates such as those used for SSL/TLS, code signing, and document signing. The recommendation was that 1024-bit RSA keys should only be depended on until 31 December 2010, after which the minimum key size should be 2048-bit RSA.  This recommendation has been adopted and published by a number of organizations:

Adobe CDS Certificate Policy

• CDS Subordinate CAs shall use an RSA key pair with at least 2048 bits.
• CDS Subscriber certificates shall use an RSA key pair with at least 2048 bits.

CA/Browser Forum Guidelines for Issuance and Management of Extended Validation Certificates

• Requires a minimum of 2048-bit RSA keys for Root and Subordinate CAs.
• Requires a minimum of 1024-bit RSA keys for end entity certificates and 2048-bit keys for end entity certificates that expire after 31 December 2010.

Microsoft Certificate Root Program

• All new Root certificates must have a minimum be 2048-bit RSA keys.
• 1024-bit Roots will be removed from the Microsoft Root Certificate Program by 31 December 2010.
• All end entity certificates issued after 31 December must have a minimum of 2048-bit RSA keys.

Mozilla Foundation dates for phasing out MD5-based signatures and 1024-bit moduli

• December 31, 2010 – CAs must stop issuing intermediate and end-entity certificates from roots with RSA key sizes smaller than 2048 bits. All CAs must stop issuing intermediate and end-entity certificates with RSA key size smaller than 2048 bits under any root.
• December 31, 2013 – Mozilla will disable or remove all root certificates with RSA key sizes smaller than 2048 bits.

The reason for moving to stronger subscriber keys is to protect the data of Subscribers and Relying Parties.  Cryptanalytic attacks against a particular key size become more practical as computing power increases and new techniques are developed.  See, for instance, 768-bit RSA key in December 2009.  A broken end-entity key could expose encrypted session data or allow a man-in-the-middle attack.

Entrust has been proactive in adopting the standards and recommendations. Entrust has put in restrictions that all certificates that expire after 2010 have a minimum of 2048-bit RSA keys. In addition Entrust is actively moving to 2048-bit root certificates. As times move forward, we will keep our eyes on the technology and the standards and implement policy to protect our subscribers and relying parties.

The bottom line is yes; our EV SSL certificates are the same as theirs.  In fact, EV SSL certificates from all certification authorities are the same.  This is because all EV SSL certificates are issued and managed in accordance with the same standard.  This standard is called the Guidelines For Issuance And Management Of Extended Validation Certificates (EV Guidelines). The EV Guidelines were developed by an industry group called the CA/Browser Forum (CAB Forum) which Entrust has chaired since 2005. 

In addition to following the same guidelines, all EV SSL certification authorities are audited by third party security auditors in accordance with criteria based on the guidelines. Proof of which is posted on the CA’s website in the form of a WebTrust for Extended Validation seal and auditor’s report.

So what’s the difference?  The difference is customer service.  Entrust provides the industry leading certificate management, combined with great customer service, and a choice of licensing models. We let our customers manage their certificates the way they want them managed … in accordance with the guidelines of course.

So why are our EV certificates so much cheaper?  Simply, we charge less. We deliver great value at a reasonable price.

The acquisition ends VeriSign’s transformation from a security software provider to simply a domain name registrar and domain name infrastructure provider. Throughout an unspecified period, security products purchased by Symantec will drop VeriSign branding in favor of a “yellow check mark” and the Symantec brand name. This seems strange in that Symantec is purchasing an established “premium brand”, then killing it in favor of their own. Whether their customers will appreciate that or not remains to be seen.

While I can’t predict what this means for VeriSign customers in the near or short term, I would like to reiterate to Entrust customers that we remain focused at providing a full range of certificate solutions and a high level of customer support. Further, given the potential disruption of this transaction it is a great opportunity to increase their share of Entrust SSL certificates!

To that end, I also want to share some new capabilities coming on board over the summer, as follows:

• Multi-Domain certificates (SAN’s) – In August 2010 we will be adding multi-domain capability to our EV certificates, as well as making it easier to purchase additional SANs for our non-EV certificates!
• Secure Email certificates – In August 2010 we will be adding secure email (S/MIME) certificates to our product offering, making it easier for our customers to secure their email communications, either through signing or encryption.
• Premier Support – Shortly we will be offering optional 24/7/365 support and priority issue handling

The changes we are making to product are coming directly to us as customer requests, so please keep them coming!