Archive for the ‘Certificate Management’ Category

« Older Entries

Could be Problems with New gTLDs

Tuesday, May 14th, 2013 | Bruce Morton

The PayPal information risk management team warns that the introduction of new generic top-level domains, or gTLDs, could impact security.Generic Top Level Domains

For many years it has been common for enterprises to configure DNS domains with suffixes that are not in the set of public TLDs. The practice has been recommended by software vendors and security experts. The public delegation of these suffixes as new gTLDs will impose serous security risks on unprepared systems and roaming enterprise laptops.

Domains to be concerned are the top-10 invalid queries from the ICANN SAC 045 report, plus those gTLD suffixes identified in RFC 6762 for Multicast DNS. They are: belkin, corp, domain, home, internal, intranet, invalid, lan, local, localdomain, localhost, private and wpad.

The CAs are particularly concerned with .corp. This suffix is proposed as a new gTLD that is most often used by CA customers. If .corp is approved as a new gTLD, then correcting its use in an enterprise will have the greatest cost; and not correcting will carry the greatest risk.

Any domains that are approved as new gTLDs will have to be addressed by the CAs. The CAs will have to review the certificates they have issued and advise customers that have certificates with a new gTLD. The customers will then have to register their domain. If the customer cannot or does not register the domain, then the CA must revoke the certificates within 120 days from the gTLD being approved, as required in the CA/Browser Forum Baseline Requirements.

If you have certificates that use a proposed new gTLD, then please take precautions. You will have to make plans to either register the domain, change to a domain that you already have registered, or obtain your certificate from a non-publicly trusted CA.

Image Source:

http://news.dot-nxt.com/sites/news.dot-nxt.com/files/gtld-letterpress-s.jpg

Tags: , , ,
Posted in Certificate Management, SSL Deployment | Add Comment | No Comments »

Self-Signed Certificates don’t deliver Trust

Thursday, April 4th, 2013 | Bruce Morton

This post was originally published on the CA Security Council blog.

We’ve heard the argument that website operators could just use self-signed certificates. They are easy to issue and they are “free.” Before issuing self-signed certificates, it’s a good idea to examine the trust and security model. You should also compare self-signed certificates to the publicly trusted certification authority (CA) model; and then make your own decision.

Self-Signed Certificate Model

  • Owner says who they are
  • Owner issues on their own policy
  • Owner is responsible for quality
  • Owner may not follow industry guidelines
  • Owner may not provide certificate status
  • Compromised certificates may not be able to be revoked
  • Owner is not audited
  • Issuer of certificate may not be authorized by the domain owner
  • Certificates may not be renewed if there are no reminders
  • Self-signed certificate model does not provide trust and the browser provides a trust dialogue box to indicate such

Publicly-trusted CA-Signed Certificate Model

  • CA verifies the owner of the domain and the certificate applicant
  • CA operates to a policy in conformance with the requirements of the browser and operating system vendors. The requirements include the CA/Browser Forum Baseline Requirements, Extended validation (EV) Guidelines and recommendations from NIST.
  • CA provides quality to the certificate. Checks include compromised keys, minimum key size, ensuring hashing algorithms, maximum validity period and proper certificate extensions.
  • CA updates policy based on industry best practices
  • CA provides certificate status through CRL and OCSP
  • Compromised certificates can be revoked
  • CA is audited to certificate issuing criteria such as WebTrust for CA, WebTrust for EV and SSL Baseline Requirements
  • Certificate requesters for a Domain validated certificate are authorized by the owner of the domain. Requesters for Organization and Extended Validation certificates are authorized by a member of the organization specified in the certificate.
  • CAs provide multiple reminders to ensure the certificates are renewed before they expire. CAs may also provide certificate discovery tools to find certificates on your systems which may not have reminders.
  • Publicly trusted CA model is based on the CA being a trusted third party to the browser/OS vendor, the website certificate subscriber and the end-users of the website. The CA is obligated to meet the requirements of all three parties.

So, when should you use a self-signed certificate?

When trust, security, service, quality and reliability are not your criteria.

Tags: , ,
Posted in Certificate Management, SSL Deployment | Add Comment | No Comments »

Mozilla Endorses SSL Baseline Requirements

Wednesday, February 27th, 2013 | Bruce Morton

The CA/Browser Forum Baseline Requirements have been endorsed by Mozilla and have been included in their certificate authority (CA) certificate policy.

The Baseline Requirements are an auditable set of certificate management requirements that were finalized in November 2011. Their purpose is to set a level of management requirements for all SSL certificates. The Baseline Requirements also apply to Extended Validation (EV) certificates, but EV has its own guidelines to manage stricter verification.

The members of the CA/Browser Forum made them effective as of July 1, 2012. For the most part, the major vendors of publicly-trusted SSL certificates have now been compliant for the last eight months. The audit authorities developed audit criteria and both WebTrust and ETSI have integrated the Baseline Requirements into their CA audit programs.

The final task was to have a browser vendor require the Baseline Requirements in their certificate policy. Mozilla has done that with its Mozilla CA Certificate Policy (Version 2.1), which was released on February 14, 2013.

Here is a high-level look at the changes included in the Mozilla policy update:

  • Multifactor authentication or limit domains for all accounts capable of directly causing a certificate issuance
  • Root certificates should only issue subordinate CA certificates. End-entity certificates could be issued from a root in accordance with Baseline Requirement section #12
  • All subordinate CAs must be technically constrained or publicly disclosed and audited
  • Technical constraints are performed by adding an Extended Key Usage (EKU) to the subordinate CA certificate that specifies the key usage that the CA is to be used to issue. The constrained CAs must also do the following for the specified certificate types:
    • Server authentication (SSL) – must also include a Name Constraints X.509V3 extension
    • Secure email – must issue certificates can only be issued for authorized email addresses or mailboxes
    • Code-signing certificates must issue the end entity certificates including a subject distinguished name with organization, locality (where relevant), state or province (where relevant) and country name
    • If technical constraints for a subordinate CA is not possible, then they must be audited in accordance with Mozilla’s certificate policy and must be publicly disclosed
    • CA operations and issuance of SSL certificates must be done in accordance with Baseline Requirements version 1.1

Mozilla also has more details and a set of frequently asked questions, including implementation dates. The bottom line is that all new CAs must meet the Baseline Requirements and all existing CAs must be audited to the Baseline requirements by February 15, 2014.

I would like to thank Mozilla for endorsing and requiring the Baseline Requirements.

Tags: , , , , ,
Posted in Certificate Management, Secure Browsing | Add Comment | No Comments »

TURKTRUST Unauthorized CA Certificates

Friday, January 4th, 2013 | Bruce Morton

Although unrelated to Entrust, I thought you might be interested in the news about TURKTRUST.

It has been reported that the TURKTRUST certification authority (CA) inadvertently issued two intermediate CA certificates in August 2011. The certificates were issued in error due to test code being moved into production. The certificates issued were for “*.EGO.GOV.TR” and “e-islem.kktcmerkezbankasi.org.”

According to TURKTRUST, on December 6, 2012, the “*.EGO.GOV.TR” intermediate CA certificate was moved to a Check Point firewall, which was configured for inspection. In this mode, the Check Point firewall automatically generates certificates for all SSL connections. In this case, it issued a “*.google.com” certificate. TURKTRUST stated that the certificate was not issued for dishonest purposes.

It is not acceptable, but mistakes do happen. In this case, the mistake was again detected by Chrome’s public key pinning, which indicated that a fraudulent Google certificate had been issued.

Most of the browsers (Google Chrome, Microsoft IE and Mozilla Firefox) took corrective action and blacklisted the inadvertent intermediate CA certificates.

What else can be done? Here are some ideas:

Limit CA Functionality – If a CA is not supposed to issue CA certificates, then disable this functionality. If the CA is only supposed to issue SSL certificates, then disable the functionality for Code Signing and S/MIME. Limited functionality will limit the risk.

Automated Certificate Inspection – All certificates that have been issued should be inspected to meet certain criteria. All issued certificates could be inspected for minimum key size, signing algorithm, CRL CDP, OCSP AIA and basic constraints criteria. If the basic constraints indicates “Subject,” then an investigation should be performed to ensure that the CA certificate issuance was authorized.

Audit – Both internal and external audits could be performed to manually inspect issued certificates. If a CA certificates is found, then an investigation should be performed to ensure it was authorized.

Certificate Transparency – We can help domain owners check for fraudulent website certificate issuance. This could be done with the further development and deployment of Certificate Transparency (CT). CT will make it possible for domain owners to inspect logs to see if any certificates were issued for one of their domains.

Updated January 7, 2013: TURKTRUST has provided an announcement and technical details.

Tags: , , , ,
Posted in Certificate Management, SSL Deployment, Technical | Add Comment | No Comments »

Should You Use SHA-2?

Tuesday, December 11th, 2012 | Bruce Morton

A common question we receive from certificate customers: should we ask Entrust to sign our certificate with a signature using the SHA-2 hashing algorithm? Here is some information to help you make this decision.

What’s the purpose of the signature?

The purpose of the signature is to allow an end-user who is validating the certificate to ensure it was issued by a trusted certification authority (CA) and, thus, determine whether or not to trust the certificate.

The CA provides the signature and can choose from several cryptographic hash functions. MD5 was commonly used until it was found to have serious cryptographic flaws. SHA-1 is currently the most widely used hash function, and the industry is now moving to SHA-2. There is also a newly approved SHA-3 hash function, which may be deployed as a substitute to SHA-2 at a future date.

The main thing you need to understand about hash functions is they are designed to be collision- and preimage resistant.

Why should I consider using SHA-2?

As time moves along, the attacks against a given cryptographic hash function often improve. MD2 and MD5 were formerly used, but are now known to be too weak for cryptographic use. The concern is that in the not too distant future the SHA-1 hash will also be found to be too weak.

What are the hash attacks?

(more…)

Tags: , , , , , , , , , , ,
Posted in Certificate Management, SSL Deployment | Add Comment | No Comments »

Certificate Transparency Birds of a Feather

Monday, November 19th, 2012 | Bruce Morton

IETF 85 held a Birds of a Feather (BoF) meeting on Certificate Transparency (CT).

CT is a method for domain owners to determine if a certificate has been issued for their domain. It will also allow an end user to distrust the certificate, if it is not logged.

A quick aside about why the concern for fraudulent certificates is going up and up. The Web security model has always been focused around finances. The financial concerns are mostly hedged by the banks who limit the loss to credit card subscribers. Then the social Internet (e.g., social media, email) came along and people started using the Internet for communication with friends — sometimes sending sensitive communication or information. The knowledge of some sensitive communication by third parties could result in a threat to their lives. The risk has been dialed up a few notches.

The big issue with certificate management is there seems to be an unlimited number of CAs that can issue a certificate for any domain. A bad certificate could be used in a man-in-the-middle attack to compromise people’s communications, invade people’s privacy and even cost lives. This was the concern in Iran after the DigiNotar breach.

CT is still very much in the draft phase. Adam Langley of Google, the main presenter, described the concept about how all certificates would have to be publicly disclosed and logged in a CT log. The solution would be accomplished without changing server software and not relying on third parties who would need uptime and the ability to be reached.

Eventually, it is desired that the browsers will be changed to require all publicly-trusted certificates to be logged. If not logged, then an error would occur. There are two CAs currently testing CT with Google.

The certificates would be logged by the CA at time of issuance with information in the signed part of the certificate. Certificates not logged this way could be logged out of band by the Subscriber or the CA.

Once there are logs in place, there would be requirements for monitors. A domain owner could review the logs for certificates issued to their domains. A third party could also set up a service that would email a domain owner whenever a certificate was registered with one of their domains.

There was much concern by the BoF regarding how CT would work with DANE-compliant certificates. It was stated that if you want your certificate to be treated as publicly-trusted, then it would need to be logged in some way. There appears to be much work to do here to make sure that all parties are happy.

It took two rounds of humming, but the BoF determined that CT should proceed along without having a working group. To support development, visit the CT website.

Tags: , , , ,
Posted in Certificate Management, Secure Browsing | Add Comment | No Comments »

Certificate Key Lengths: Bigger is Better

Friday, September 7th, 2012 | Scott Shetler

As previously discussed,  Microsoft issued a security advisory announcing they will block keys that are less than 1024 bits long. This feature will appear in an update for supported versions of Microsoft Windows (not affecting Windows 8 or Windows Server 2012; the functionality is already there) and, of course, you have to upgrade to this version for this feature to activate.

What is the impact to you? Possibly nothing. Even 1024-bit keys are not recommended anymore, especially over larger 2048-bit keys. In fact, 1024-bit keys currently cannot be signed with end dates greater than December 31, 2013, for publicly trusted certificates. As a result, 1024-bit keys are also going the way of the dodo, albeit a couple of years behind.

However, if you do have keys sizes smaller than 1024 bits in your environment, they will not be recognized on Windows machines with this update applied, potentially breaking an application or causing an outage. And even if you don’t apply the update on your application server for example, that doesn’t mean you won’t suffer — browsers who apply the patch will not be allowed to access sites with small key sizes, effectively breaking your site anyways.

Microsoft recommends four methods of discovering small RSA key sizes in your environment:

  • Check certificates and certification paths manually
  • Use CAPI2 logging
  • Check certificate templates
  • Enable logging on computers that have the update installed

Here’s another idea: use an automated certificate discovery tool to scan your hosts/ports and CAPI stores and build an inventory upon which you can then set policy alerts when key sizes don’t meet your policy.

Tags: , , , ,
Posted in Certificate Management, SSL Deployment | Add Comment | No Comments »

Microsoft to ban keys less than 1024 bits

Friday, June 15th, 2012 | Bruce Morton

For those of you who do not maintain the size of your keys for digital certificates, you’re about to have some problems. Microsoft is not a proponent of small-sized digital keys. Their Windows Root Certificate Program does not allow CAs to issue certificates with keys less than 1024-bit RSA and deprecates keys that are less than 2048-bits RSA. This is in line with the NIST recommendations to move to a minimum of 2048-bit keys by January 1, 2014, and also with the CA/B Forum Baseline Requirements with the same specification.

In August 2012, Microsoft will introduce a new patch to the following operating systems: Windows XP, Windows Server 2003, Windows Server 2003 R2, Windows Vista, Windows Server 2008, Windows 7 and Windows Server 2008 R2. The update will block the usage of cryptographic keys that are less than 1024 bits. The result will introduce problems when going to an SSL site, enrolling a certificate, creating or consuming S/MIME email messages, installing Active X controls, or installing software where a small cryptographic key has been used.

If you only have publicly-trusted certificates from reputable vendors, there’s nothing to worry about. Public CAs, such as Entrust, do not issue certificates with small keys and have plans in place to move to a minimum of 2048-bit keys by January 1, 2014.

However, if you are like most organizations we talk to, you likely have certificates signed by various CAs. Some users may have problems, come August, if their certificates have been issued from an internal CA that does not follow the common certificate policy rules.

Entrust does offer a solution called Discovery, which helps you inventory all your digital certificates, from any vendor or source, and set policy regarding key size. With Discovery, you are alerted to certificates with key sizes that are outside your policy.

Tags: , ,
Posted in Certificate Management, Secure Browsing | Add Comment | No Comments »

First New gTLD Requests

Thursday, June 14th, 2012 | Bruce Morton

ICANN has published the first new gTLD requests. If approved, these gTLDs will add to the current 22 generic TLDs and the 280 country code TLDs. The new gTLDs have mostly been requested by companies and governments. We see that Google has asked for .youtube and Ford has requested .ford. Amsterdam and London have asked for .amsterdam and .london. There are many other requests such as .beer and .sucks.

As I stated in my previous post, if your websites have SSL certificates using internal domain names with one of the requested new gTLDs, then you should start making plans to either move off of those names or register them in the future. If you don’t own your domains ending with the new gTLD, then your public SSL CA will not be able to issue you a certificate with that name.

Screenshot from ICANN

Tags: , ,
Posted in Certificate Management, SSL Deployment, Secure Browsing | Add Comment | No Comments »

Secure gTLD

Friday, May 18th, 2012 | Bruce Morton

As a follow to my post on new gTLDs, here is an interesting request for a gTLD called .secure.

Artemis Internet is planning to provide secure domain names. Security will be provided through human verification, security policies, and enforcement. The .secure gTLD would be available to any organization or individual. The users would have to follow a strict code of conduct including rigorous identity screening, two factor authentication, meet a minimum set of security practices, and end-to-end encryption of most traffic.

The Artemis CTO says, “We have a chance to create a neighborhood on the Internet where security is required, and users know that. We have the ability since we’re starting from scratch to have a floor.”

This could be a great implementation for a new gTLD. As I said before, the requests for the gTLDs must be assessed and approved and there is more than one request for .secure. We’ll see what happens.

Attribution: Photo is a screen capture from Artemis.net

Tags: ,
Posted in Certificate Management, SSL Deployment, Secure Browsing | Add Comment | No Comments »

« Older Entries