SSL

With our Entrust Certificate Services release yesterday, we made significant improvements in the way we offer multi-domain (or multi-SAN) certificates.

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.

On Tuesday, Aug 17^th, Entrust is releasing a new version of it’s certificate management service, and included in that version among other things are new secure email certificates! We have 2 flavors launching: one for individuals that offers a low assurance ID with limited bells and whistles, and one for enterprises that offers a medium assurance ID, with more advanced capabilities, like a web certificate request form for end-users to request their certs, admin approvals of requests, and unlimited certificate re-issues. 

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!

Back in 2005, Adobe unveiled the Certified Document Services (CDS) program, which automatically trusts new digital IDs that are chained to (part of the family of) the Adobe Root certificate embedded in Adobe products. Anybody who opens a PDF document signed or certified by a CDS credential automatically gets a “blue ribbon” with trust provided to the signature without any user interaction. 

 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

There has been an interesting development in the SSL market since our last blog – the acquisition by Symantec of the entire security product portfolio of Verisign, including GeoTrust and Thawte.

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!

I guess its not that surprising, but a new report indicates that .47 percent of banking customers fall victim to a phishing site every year.  This clearly demonstrates that phishers have a large market to address and are obviously seeing a return on their investments.  That means we can expect to see even more phishing attempts going forward.  Financial institutions already are facing an average of 16 attacks a week.  One wonders how many more they can cost effectively deal with?

Naturally, the targets of these phishing attacks are becoming educated about phishing so that will mean phishing attacks will become more sophisticated.  Case in point: some phishers have taken to social media such as Facebook and Twitter (“friending” the wrong person in Facebook can provide enough information for identity theft).

One defense against phishing is EV SSL certificates.  It’s a step in the right direction that applies stringent verification standards on those that want to use one.  When deployed, EV SSL certificates display the verified company name in the “chrome” of the browser, along with other trust indicators such as turning the address bar green.  It’s up to the browser manufacturers to decide how to display that trust.  Some turn the entire address bar green while others only shade address text green.  I wonder if consumer pressure will bring them to be more aggressive displaying verified company information.  Time will tell.