web analytics

Chain Certificates

Oct 29

What are chain certificates? Chain certificates are referred to by many names — CA certificates, subordinate CA certificates or intermediate certificates.  Confused yet? Let’s break it down.

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.

View the original article here

Read More

Where are your digital certificates?

Oct 29

Over the years, Entrust has had many conversations with customers trying to improve or strengthen enterprise and customer security within the online channel. And one topic that repeatedly comes up is certificate discovery and management. Their specific challenges can be grouped into three distinct categories:

Unexpected certificate expiryConcern about data breach or non-complianceManagement headaches

Even though most certificate issuance systems now use e-mail notifications when certificates are about to expire, customers still feel the pain of unexpected expiry. Either certificates are issued off a non-policy CA, or certificates they know about (and are notified about near expiry) have been copied to other locations that weren’t considered during the renewal process.

Also, customers may have deployed certificates that don’t meet their minimum crypto-policy. This can result in non-compliance or leave their organization exposed to possible data breach. Without an accurate list of encrypted network assets, customers can absolutely be at risk — and unable to sleep at night.

Understandably, customers experience headaches when forced to deal with multiple certificate issuance systems. Even worse, managing certificate locations and ensuring the right assets are protected — to the right level, for the right amount of time — is downright challenging.

In the end, organizations can’t solve this pain if they don’t know where the certificates are deployed. But by talking to customers about real-world challenges, we’ve developed an important service that addresses these very issues.

Entrust Discovery, a streamlined certificate inventory and management solution, scans your network to find and manage server and device certificates. It’s intuitive, user-friendly and truly simplifies the process of locating, inventorying and management digital certificates — regardless of which organization issues the certificate.

Whether the Software-as-a-Service (SaaS) or customer-premises model, I believe most organizations will find tremendous value in this easy-to-use-solution.

This entry was posted on Friday, October 8th, 2010 at 3:37 am and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

View the original article here

Read More

SSL Security Silly Season

Oct 28

You can tell that summer is here as the SSL security silly season is just warming up. This is the time of year when we start to get a preview of what will be presented at the annual Black Hat and DEF CON conferences.  The season was in full swing when at a recent Black Hat Preview Webcast, noted security expert Ivan Ristic of Qualys, was quoted as stating “we have about 22 million SSL servers with certificates that are completely invalid because they do not match the domain name on which they reside.”

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.

Tags: ,

This entry was posted on Thursday, July 8th, 2010 at 5:56 am and is filed under Technical. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

View the original article here

Read More

Online SSL Tools

Oct 28

So you’ve gone to the trouble of buying and installing an SSL certificate.  How do know you installed it properly?  Some would just test the site by trying it with their browser. The problem is that Internet Explorer and Firefox validate the certificate path differently.  Firefox will install an intermediate certificate while IE doesn’t.  IE validates the shortest path, while Firefox validates the full path. There are other desktop browsers such as Opera, Safari, and Chrome and then the mobile browsers.  The best thing to do is to use an OpenSSL based tool to do your checking.

Entrust has such a tool.  Once you install your new SSL certificate, all you need to do is key in your fully qualified domain name into Entrust SSL Install Check and click verify.  The tool will validate your SSL certificate installation, confirm your IP address and server type and tell you if all chain certificates have been installed correctly. If any of the certificates are missing, the tool will provide instructions to fix the problem.

You can also check the status and validity of SSL certificates that you have previously installed. In addition to the checks above, SSL Install Check will tell you if the certificate has expired or has been revoked.

Other sites have SSL tools as well.  The SSL Shopper tools page includes tools for CSR decoding, certificate decoding, and certificate format converting.

One tool I find very useful is the Public SSL Server Database / SSL Server Test tool at Qualys SSL Labs. This tool provides an overall assessment of how your web server has been configured for SSL.  It provides a letter grade based on the SSL certificate, protocol support, key exchange and cipher suite. The scores are explained in an SSL Server Rating Guide.

For quick reference here is a list of the online SSL tools mentioned above:

SSL Install Check
CSR Decoder
Certificate Decoder
SSL Certificate Format Converter
Public SSL Server Database / SSL Server Test

View the original article here

Read More

Quality vs. Quantity: SSL Certificate Verification Practices

Oct 28

VeriSign announced that GeoTrust (a VeriSign subsidiary) SSL certificates are most often used to secure the most-visited web sites. This was established by cross-referencing the Alexa 1 Million with the July 2010 Netcraft SSL survey. The results revealed 35,142 unique domains protected by GeoTrust SSL certificates out of approximately 165,000 of the Alexa 1 Million on which Netcraft found certificates.

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.

View the original article here

Read More