Earlier this year, new industry standards were adopted which made Certificate Authority Authorization (CAA) record checking mandatory for all Certificate Authorities.

This gives website administrators an additional tool for protecting their sites from mis-issuance, and a technical measure for enforcing an organization’s certificate policies.

Introduction to CAA

By setting up a CAA record you can control which CAs are permitted to issue certificates for your website. This addresses one of the key concerns of the Web PKI system—that any single CA can be used to compromise any website. Typically, only a handful of CAs are used by a single site, making it unnecessary to allow every CA in the world (on many platforms there are around 100 trusted CAs) to issue certificates for your site.

When a CA receives a certificate request, they must first query that website’s CAA record before validating or issuing the certificate. CAA records are a new type of DNS record that websites can optionally configure for these additional protections. In September 2017, new industry regulations required all CA’s to check for a CAA record before issuing a certificate.

CAA deployment has grown significantly this year. SSL Pulse, which analyzes SSL configurations of the world’s largest sites, reports that the number of sites using CAA has doubled since September 2017, and increased more than tenfold this year. Even with that rate of growth, only a few thousand websites are using CAA and it remains a niche security mechanism.

One of the common misunderstandings about CAA is that websites are forced to use it. This comes from confusion over the core mechanics of CAA. By default, a website with no CAA record has no restrictions on which CAs may issue certificates to it.

A CAA record allows you to restrict the list of approved Certificate Authorities through a whitelist. For websites that are not interested in CAA, they do not have to make any changes. Simply don’t create a CAA record and every CA will be able to issue certificates for your domain.

Policy Enforcement

CAA is not only a security mechanism. In addition to minimizing risk by restricting the CAs authorized to issue for your domain, CAA is also a useful tool for enforcing company policies related to certificates.

Many organizations struggle with making sure that company policies related to purchasing, requesting, and deploying certificates are obeyed. This is especially true in large organizations with multiple offices or semi-autonomous departments. CAA can act as a technical measure for enforcing your certificate policy.

For example: say someone in engineering sets up a new service on your domain. If they attempt to request a certificate they will be restricted from using CAs you have not approved. You can optionally configure a reporting URL or email address to receive notice from CAs when they receive a request they are not permitted to issue.

Deploying CAA

CAA is a new security mechanism that can be used to strengthen your website’s SSL configuration and certificate policy. Given that most administrators have never deployed CAA, we have put together a short summary of the process. CAA is a rather easy mechanism to use, and carries significantly less risk of configuration or operational errors than other mechanisms like strict transport security (HSTS) or key pinning (HPKP).

There is a technical pre-requisite to using CAA. If you use managed DNS, your provider needs to have added support for CAA because it is a new DNS Resource Record. Many major providers, including Cloudflare, Dyn, and Route 53 support CAA. SSL Mate maintains a list of major providers and their support here.

Here are guidelines for planning a CAA deployment, and an overview of how its deployment benefits your website security and organization’s policy:

1. Use your organization’s certificate policy as a starting point. If you have approved certain CAs as providers, use these to create the list of CAs you will enter into your CAA record.If you do not already have a certificate policy at your organization, at a minimum you will want to determine what CAs are commonly used by your organization. You can always update (or remove) your CAA record if you need to change the list of authorized CAs, and those changes take effect according to your DNS TTL.

2. Create a CAA DNS record. Your policy can be restrictive—scoped to only one or a handful of CAs your organization uses—or more flexible to allow your organization to use a larger number of popular providers. Even if your CAA policy permitted 10 CAs, this would still be a significant reduction.Here is an example of a CAA record which would only allow DigiCert to issue certificates for a website:

   yourdomain.com.       CAA 0 issue “digicert.com”

   This record would apply to all subdomains under the domain.  If you wanted to permit additional CAs, a new line would be created for each CA. The hostname listed at the end identifies the CA, which each CA explicitly choses. That hostname may not be the same as the CA’s homepage, so make sure you check with your CA’s documentation for the proper syntax. SSLMate provides a free CAA record generator tool to streamline this process. Note that you can set different CAA records for subdomains for more flexibility. CAA records are checked hierarchically in your DNS tree, starting at the highest label of the request. For example, if you requested a certificate for “sub.domain.com,” the CA first checks for a record for the subdomain, then the root domain if a record does not exist at the subdomain level. For CNAME’s the parent domain will be checked last.

3. For all future certificate requests your domain’s CAA record will be checked and any CA but DigiCert (in this example) must refuse to issue any certificates.As of September 8, 2017, the CA/B Forum now requires all CAs to obey a CAA record. This applies to all trusted CAs, including certificates provided for free and by cloud service providers. Failing to obey your record constitutes mis-issuance of the certificate which can lead to sanctions or dis-trust of the CA.

4. Your domain is now at reduced risk for mis-issuance. In an adversarial scenario, a potential hacker would be constrained to the CA(s) specified in your CAA record, creating less attack surface.Depending on how your CA implements account controls, this could make it impossible for attackers to receive certificates for your site, even if they compromised your web server. For example, if your CAA policy only permitted DigiCert to issue certificates for your site, there would be no way for the attacker to complete the OV/EV validation process.Employees or unauthorized users would similarly be restricted, which reduces violations of your org’s certificate policy. In the future, CAA could be expanded to allow for more fine-grained control, such as restricting validation type.

   In a scenario where a specific CA has vulnerabilities in their validation or issuance procedures, there is a reduced chance your domain will be affected. If CAA had been deployed and enforced in 2016, many of the highest priority mis-issuances in the Web PKI ecosystem may have been prevented.

CAA does have limitations. If a CA is acting maliciously—either because they have gone ‘rogue’ or have been compromised by an attacker—they can simply ignore what your CAA record says and issue certificates anyways. Individual websites are also at risk if their DNS is compromised. An attacker who can change your DNS settings could remove your CAA record, which would allow all CAs to issue for your site again. This could also be achieved with DNS record spoofing, though only very powerful attackers would have that capability.

A final note: CAA only addresses certificate issuance of trusted CAs. It is not intended to deal with scenarios where local root certificates are trusted on a device, such as a corporate intranet. Those roots would still be free to issue certificates for your domain as they are not regulated by root programs. This could be used to intercept or monitor traffic to your website on a local network.

After much anticipation, I’m happy to share the news that we completed our acquisition of Symantec’s Website Security and related PKI solutions, becoming the premier provider of SSL/TLS and PKI solutions. We enthusiastically welcome our new Symantec customers, partners, and employees.

Now that the deal is complete, our two organizations can start working to build an even greater security company together. We are committed to working through this acquisition the right way—making the transition seamless for customers and partners, integrating processes, and coordinating with browsers.

Since announcing the acquisition, DigiCert has actively engaged with the security community to explore paths that address browser concerns about Symantec-issued certificates while balancing the TLS implementations currently deployed. This plan is close to completion and will minimize impacts, allowing customers to continue securing their transactions.

Symantec-issued certificates impacted by the browser timelines will need to be replaced. These will be replaced at no cost at the appropriate time, and we’ll work to ensure a smooth process. Many customers have already received information on certificate replacement, and more information will be forthcoming for affected parties.

What Symantec Customers & Partners Can Expect

DigiCert has gained a strong reputation in the industry for being fast, reliable, and responsive. Known for our exceptional customer support and fast issuance, we’re excited for Symantec customers to experience this level of service in addition to our industry-leading OCSP response times, and award-winning PKI and IoT management platforms.

We built our infrastructure for scale and performance, which is especially important as we take on the Symantec Website Security and related PKI business. DigiCert systems are designed for high-volume deployments for SSL and IoT and are stress-tested for billions of certificates. As such, we’ll be able to continue providing industry-leading issuance times, even with the added Symantec business.

In the coming months, our customers will enjoy the benefits of best-in-class products and services as we bring together the technology from both DigiCert and Symantec. This includes DigiCert’s SSL and private PKI services and leading PKI-based solutions for IoT device security with automated certificate management.

For now, Symantec customers can continue to order and purchase certificates the same way they always have. In addition, they can still use existing Symantec management tools. Account management contacts, existing contracts, brands, and validity periods for certificates will remain the same, as does pricing.

Partners will also be able to offer their customers an even wider range of solutions, drawing from the portfolio of Symantec and DigiCert security offerings. As the world leader in SSL and PKI, our partners play a crucial role in helping us deliver identity, authentication, and encryption for the web and IoT.

What DigiCert Customers & Partners Can Expect Going Forward

From the beginning, DigiCert has been driven by helping our customers and solving pain points for SSL and PKI management. With the addition of Symantec’s Website Security to DigiCert, we’re bringing together the top talent in the industry, which will help us accelerate our efforts to simplify SSL and PKI solutions. DigiCert will continue to participate in industry groups, where we help shape security standards and make sure you stay at the forefront of security practices.

We know there will be questions and we’ll strive to be transparent by keeping our customers and partners updated with regular communication. If you have questions about your specific situation, customers and partners can continue to reach out to us using the same methods you’ve always used, whether through your Symantec or DigiCert account rep, or by contacting our Support teams.

We’re committed to our customer-first philosophy while building upon our legacy as a security industry leader. Thank you for your continued loyalty.

John Merrill, CEO

That’s one heck of a headline, I know, but things just got real for Wi-Fi security Monday morning. Mathy Vanhoef of imec-DistriNet and Frank Piessens at KU Leuven published the results of their hard work on the authentication mechanism of the WPA2 protocol (which is used by Wi-Fi as a security layer for data traveling over the connection)—and it’s totally broken.

If panic just set in, you can find more detailed information on the attack here. However, keep reading if you want to understand this attack from a high level and how it impacts IoT devices.

What is the KRACK attack?

The KRACK attack focuses on the four-step protocol used during the setup of a WPA2 Wi-Fi connection. The result is that an attacker, within range of the Wi-Fi router, can break the encryption on the connection allowing a secondary attack using a man-in-the-middle (MITM) attack to gain access to all HTTP data being sent from the client and data being received from the server. Your services and devices utilizing HTTPS should be ok because even if the attacker were to gain access to the connection, your data is encrypted by the HTTPS layer.

WPA2 utilizes this four-step negotiation process to set the encryption key for communication with a Wi-Fi access point, and can be tricked into using an incorrect key that allows the attacker to gain full access to the communications.

The weakness that KRACK exploits is at the protocol level within Wi-Fi, leaving all clients susceptible. However, Android and Linux client libraries are uniquely susceptible to a vector of this attack that resets the encryption communication key to a “Null Key” (a key with all zeros), making the attack more accessible and effective on those platforms. Android and Linux just have an additional bug that makes exploit a bit easier in this case.

This vulnerability means that all of the numerous client devices that utilize Wi-Fi in use today will need to be updated to prevent this attack from occurring. Wi-Fi routers and enterprise class equipment should get new firmware quickly, but IoT Devices, where update may be difficult or impossible to apply, will be hit the hardest.

What does this mean for IoT devices?

There are varying types of IoT devices including (but not limited to) devices used for industrial, healthcare, scientific, entertainment, home control and automation, and personal fitness purposes. The threat level of these devices varies widely, as does the implementation security levels each one uses.

A simple exercise to measure the spread of IoT devices would be to look around your home. You may have things like a smart TV, smart appliances, Amazon Dash, home security, sprinkler systems, smart meters, printers, and other home automation devices. This grows by an order of magnitude when you look into the enterprise setting.

Some IoT devices may only utilize HTTPS for the authentication step, but subsequent communications can occur over HTTP. Some IoT devices may utilize HTTPS for authentication and communication, but have other device services that are not utilizing HTTPS. Others may not utilize HTTPS at all. Those are the devices which will be impacted the most by the KRACK attack.

Let’s take a look at the simplified communication structure between a fictional home thermostat and the service provider for the device. The graphic below demonstrates the device sending a request to authenticate and receiving a response telling the device to update its firmware (two ordinary things that an IoT device can do). The request goes through the Wi-Fi Access Point (AP) to reach the service provider. The service provider sends the data back to the device, again, through the Wi-Fi AP.

As you can see in the graphic above, if an outside attacker can gain control of the Wi-Fi AP by breaking the encryption and setting up a MITM, and the device is not using HTTPS for communications, then the attacker would have the full capability to intercept the authentication credentials and inject anything into the response for a firmware update.

Now, to be fair, many devices may utilize HTTPS connections for a lot of the communications they use, and are thusly not impacted by this portion of the attack, but IoT security doesn’t stop there. Let’s say that a server response was over HTTP (as in the example above) for a firmware update request, and the attacker injected a URL to a compromised firmware binary image. The device would now install the firmware and introduce whatever additional vulnerabilities or trojan type services that the attacker is trying to use.

This creates many larger problems, and we will talk about how to manage these situations below.

How can I remediate this attack for IoT?

First, if you produce IoT devices then you need to update your Wi-Fi drivers, especially if you have Linux or Android (6+) on that device. While you are doing this you should also disable weak cipher suites to avoid future vulnerabilities around crypto and HTTPS.

That may sound simple, but it seems we are in a holding pattern waiting for some vendors to patch this vulnerability, so in many cases you may be waiting until your vendor(s) make a patch available.

You can follow this list to see if your device has been patched. Another helpful list of vendor solutions is here.

Aside from the Wi-Fi driver itself, there are three other general security considerations you should be mindful of as you are creating a IoT device infrastructure:

• Use HTTPS
• Use client certificate authentication
• Use code signing

HTTPS

All communications coming from and going to your IoT device should be over SSL/HTTPS. You should ensure you have a properly configured HTTPS stack on your device so that certificates are authenticated properly and trust can be made.

Client Certificate Authentication

All IoT devices should authenticate to the services they are talking with. You can pretty seamlessly include client certificate authentication in your device provisioning process to provide a cryptographically secure mechanism of authentication with the backend services. You can additionally provide revocation services on a credential like this, which is more difficult to do with password-based authentication.

Code Signing

The code that executes on the device itself should be signed. This will allow the device to ensure that it is only installing and executing code that came from a trusted source (you). If you utilize code signing, you provide a layer of security that will help mitigate the potential effects like the KRACK attack where someone may attempt to alter your firmware or applications running on the device.

Those are three generally good things you can do to provide a more robust layered security solution for your IoT device deployments.

What can I do for the devices in my company?

If you’re managing enterprise or SMB IT, assets you will want to also check with the vendors of the client devices that are on your network to ensure that they get updated.

One other internal attack vector to consider is internal employee systems, portals, dashboards, or services that maybe aren’t running over HTTPS. Now would be a great time to make use of an internal CA and create certificates for all those connections, or find a vendor that offers solutions and have them help you.

Help others by providing HTTPS for external resources that don’t already have it. If your company does provide some external services in use by others, ensure that YOUR company is serving all traffic for those resources over HTTPS, and if you control executables that are distributed, you should be code signing those as well. This will greatly help mitigate the effectiveness of attacks like this KRACK vulnerability.

Conclusion

This is a troubling development for Wi-Fi authentication, but you have to consider the threat level and how it applies to your resources. Also, remember that the attacker needs to be near the Wi-Fi network and device that is attempting to connect to it, so this is NOT a remote exploit that opens your entire environment to attack.

You will need to carefully watch your vendors and ensure that your Wi-Fi drivers and Access Points are up to date as soon as the vendors have those patches. In the meantime, ensure that all services you CAN control are running with HTTPS. That is the best you can do for right now.

This is a contributed blog post written by Brian Trzupek. Brian has deep technical expertise in a variety of areas including encryption and authentication. 

In our fourth and final interview on building a scalable PKI, we ask Darin how we should automate certificate management.

But first, let’s recap the series up to this point: We started by giving you a high-level overview of some of the critical PKI use cases. We then delved into the difference between public and private PKI. Next, we presented information to help you figure out whether your private PKI should use a hosted or internal CA. Now, we move on to considerations for automating certificate management to turn your PKI into an efficient machine.

But, how do you do that? We start by asking Darin about tools that help organizations automate certificate management. 

What tools do I need to automate certificate management?

DA:

In past interviews, we talked about using certificates on your organization’s devices, so that when they connect to the Virtual Private Network (VPN), they must provide their username and password, plus a certificate. Your next question will probably be, “Are there any certificate management software solutions out there to automate this?”

However, if you already have enterprise device management software (which you likely do, depending on the number of devices you manage), I’d suggest finding a CA that will work with you to deliver certificates down to your devices by integrating with those software solutions you’re already using to manage your devices. A good example of this is our REST API integration with Venafi. 

How do these integrations for automating certificate management work?

DA:

One of the things you should find out is whether the CA you’ve chosen offers APIs for you to program against. When I say program against, I mean that you can use the RESTful API endpoints as part of the programming you’re doing on your side.

This could be full programming where you start from scratch to create scripts that are kicked off by a service. For example, devices might hit the server. The server then kicks off the script that hits the API endpoint, requests the cert, pulls the cert back down, and passes it to the device.

Another example is a software that’s already written for some of the certificate management, but you need to write a little piece that says, when the cert gets requested, send that cert request information off to this script, and that script ends up being sent to the API.

What are some examples of software that can integrate to automate certificate management?

DA:

This model can be applied for a variety of software solutions, including Venafi, AirWatch, Casper, Tanium, and others. These solutions are already written to manage delivery of packages down to your laptops and other devices.

For example, Venafi allows you to install an agent on the server. Then, the Venafi server can speak with that agent to manage the SSL certificates. Venafi has worked to integrate with CAs, like DigiCert, and even private CAs like Microsoft CA for certificate issuance.

For example, the Payment Card Industry (PCI) requirements govern how enterprises that deal with people’s credit card information must manage their services. Some of these requirements involve knowing what’s on the device. If you fall into this category, you likely already use tools like Venafi, Airwatch, or Casper.

Are there options other than API integrations for certificate management?

DA:

Another option is Simple Certificate Enrollment Protocol (SCEP). This requires a SCEP agent on the device, and works in conjunction with enterprise device management software. The software sends a script down to the device, telling it to go get a cert and providing the configuration information to hit the SCEP service.

Then, the SCEP service takes it from there to get a cert on the device. The benefit of this is that any device that supports SCEP (Android, Microsoft Windows, Apple, Linux and other operating systems support SCEP agents) makes it quicker to go from proof of concept to production because it’s already an established protocol.

So, the benefit of SCEP is that the agent already knows how to request and retrieve certificates to the device. The agent will automatically put it into the operating system’s key store. Some enterprise device management systems have this capability, but this is a question you should ask your software provider. If your software has this capability, something like the DigiCert REST API could take the place of the SCEP agent.

As the successor to SCEP, Enrollment over Secure Transport (EST) is almost identical, except that EST supports Elliptic Curve Cryptography (ECC).

The fourth major option for automating certificate management is Microsoft Active Directory (AD) Auto-enrollment. This can be used for automating certificate delivery to the Microsoft Key Store on all Windows PCs and servers.

For servers, Internet Information Services (IIS) uses the Microsoft certificate store. Other Microsoft services, like Exchange Server, use the Microsoft certificate store. But, other web services can be installed on Windows that don’t use the Microsoft certificate store. If you’re running a Tomcat server, the cert would need to be extracted out of the Windows store to be used by the Tomcat service. It would need to be in a Java Key Store file instead.

In this scenario, it might make more sense to use a RESTful API for automatic spin up of those server types. Let’s say you have a big project where you’re going to have to spin up and spin down servers that are running a Tomcat web service, and each one needs a certificate. If you want to automate everything using scripts, you would be better off using a RESTful API.

So, how do I know which of these solutions is best for my network?

DA:

Deciding whether to use an API, SCEP, EST or AD Auto-Enrollment depends in large part on the technology you’re dealing with. It can also depend on the key type. For example, SCEP works for certs that are the RSA key type, but if it’s Elliptic Curve, SCEP won’t work—EST will.

What it breaks down to is the technology you have in place. If you’ve already been using Microsoft AD, it might make the most sense to use AD Auto-Enrollment. If you have enterprise device management tools that support API integrations with a CA’s API, you can move certificate management into your existing workflow that way. No matter what mix of technology you’re working with, a RESTful API can be customized to fit your needs.

What if I’m a manufacturer of connected devices?

DA:

For the Internet of Things (IoT), a RESTful API usually works best for automating certificate delivery to connected devices. These manufacturers are writing the software on the devices. They’re writing the cloud services software. They know how to talk to their devices. To add in certificates, it’s just a simple question of adding a simple piece on their cloud service that knows how to talk to the RESTful API.

So, you have four major options for automating certificate processes:

• RESTful API
• SCEP
• EST
• AD Auto-enrollment

Well, that wraps up our series on how to build a PKI that scales. How would you summarize the entire series?

DA:

I’d summarize building a scalable PKI in six steps:

As a security engineer, your first step is to evaluate your own environment. This is something I’m always walking through with customers. There are always certain “must-dos”—You must protect your web services for data entry, you must protect your databases for access to knowledge, you must protect your network from external access, you must verify authenticity of messages being transferred on your network. These are high-level concepts, but as a security officer, if you define these concepts first, a bunch of issues fit under them.

Then, with your knowledge of PKI, you can use signing to identify the sender of a message, encrypt and decrypt messages, protect your network for access, and more.

Next, you’ll want to understand what devices will need certificates. From there it’s a question of how to get certs down to these devices, and whether your device management software can help you do this via API integrations.

These steps will give you greater confidence and a higher success rate as you seek buy-off from senior management. Good luck!

We’d like to thank Darin for his expertise and for taking the time to do this interview series on building a scalable PKI. If you’d like to chat about your own PKI needs with Darin, or another DigiCert PKI architect, call 1.801.701.9690 or email enterprise@digicert.com.

Let the National Health IT Week parties commence! But, before we do, let’s reflect on the progress and growth the industry has seen over the last decade.

The Background & Growth of Health IT

When I began my career in healthcare 12 years ago at the US Department of Health and Human Services (HHS), the adoption of health IT was in it’s infancy. At the time, there were hundreds of IT vendors selling products of all types that promised improvements in efficiency, medical errors, transportation of medical data, and a myriad of other benefits. Because of the large volume of vendors in the space, many that worked in the industry struggled to know which products were best suited to help them achieve the promises of Health IT.

Under the leadership of then HHS Secretary, Michael O. Leavitt, the Department formed a group called the Health Information Technology Standards Committee (HITSC), involving many industry thought leaders to establish baseline standards for health IT around functionality, interoperability, and security.

This work eventually led to the creation of the Certification Commission for Health Information Technology (CCHIT), which evaluated and certified HIT vendors based on the standards created by HITSC. IT vendors started certifying their products, and this gave more confidence to those buying IT products in healthcare because consumers knew certified products at least met a baseline standard. This effort also caused many of the bad vendors to move out of the market as they couldn’t keep up with the standards that were now in place.

Following these efforts, the adoption of health IT began to accelerate but most of the growth was seen in metropolitan areas. To spur the adoption of health IT in rural communities, Secretary Leavitt decided to leverage the power of the Centers for Medicare and Medicaid Services (CMS).  The department developed a Medicare demonstration project that offered healthcare organizations incentive money if they adopted CCHIT certified technology and demonstrated clinical and process improvements. The money acted as a dangling carrot and triggered increasing adoption in smaller communities.  When President Obama came into office, his administration quickly decided to move this project out of demonstration and make it a national project with $20 billion in incentive money tied to it. This project is now commonly known as Meaningful Use.

I wanted to provide this background to highlight significant activities and efforts that have dramatically improved the state of and adoption of health IT.

Despite the progress, we are still far from a state of nirvana, where we realize all of the great promises the technology can bring. The healthcare IT industry still faces challenges.

Challenge: Interoperability

One of the challenges we still face is the interoperability of clinical data.  Many of the EHR systems still refuse to open the doors and communicate and share information with other systems. These walls need to come down so patient data can freely follow the patients, allowing them to be armed with a complete history of their medical care, so doctors can better treat them.

Not only does interoperability enable more coordinated care, but as healthcare delivery and payment increasingly shifts to value-based care, interoperable health IT is essential to the effective communication that will help improve the quality of care, better the health of communities, and lower per capita costs.

Challenge: Cybersecurity

Another issue facing the adoption of HIT is cybersecurity.  With the recent attacks on Anthem, St. Jude Medical, and the wide-spread ransomware attack known as WannaCry, it’s clear the health IT systems being used throughout the industry aren’t secure. Cybersecurity needs to become part of what we do instinctively in the industry.

During the 2016 Winter Olympics, Anthony Ervin an American swimmer, won gold in the 50-meter freestyle. He is the fastest short distance sprinter in the world. To win an event like that, your mechanics must be perfect. If any mistakes are made, it’s the difference between 1^st and last place. The amount of practice put into developing those perfect mechanics is mind-boggling. Good mechanics are not developed overnight. It requires consistent effort, practice, making mistakes, and learning from them.

Healthcare is in it’s infancy in establishing mechanics around cybersecurity. Integrating good cyber practices into the DNA of healthcare isn’t going to be easy and will require resources and new people with different skill sets. However, it is of utmost importance that we begin making cybersecurity part of what we do with health IT.

Health IT has come a long way since 2004 and the industry is better because of it. My career has been focused on the adoption and use of this critical technology that offers the promise of efficiency and clinical quality. In recent years, I’ve transitioned to focus more on solving the cybersecurity challenges our industry faces. As connectivity becomes part of all IT systems in our industry, good security mechanics are not optional. The time for action is now.  Now…let’s enjoy the week and celebrate!

Earlier this year at its Worldwide Developer Conference (WWDC), Apple announced Safari 11 and gave audiences a preview of the new features for the browser, including a redesigned error pages for SSL certificate warnings.

Safari 11 was officially released last week for macOS and ships with the latest version, High Sierra.

The new certificate warning UI is an important improvement for Safari, and the first major change to its security UI in years.

Understanding the Importance of Security UI

Certificate validation—the process of evaluating if a certificate is trusted—is one of the primary tasks a browser performs to establish an HTTPS connection. This includes a number of steps, including checking the digital signature, ensuring the certificate is valid for the hostname you are connecting to, and evaluating the certificate chain. From a technical standpoint, all major browsers handle validation correctly.

However, browsers need to provide more than technical competence. Invalid certificate warnings with jargon-riddled error messages, coupled with a UI that makes it easy to ignore certificate errors, create security risks.

Browsers serve their user and have a responsibility to consider how the UI they provide enables their users to make a safe decision. In previous versions of Safari, when a user encountered a certificate error, the certificate viewer would open and include an error message, but the wording was unclear and it was not user-friendly. Here is the old error UI from Safari versions 9 and 10:

For the everyday, non-technical audience, this UI did not enable them to make a safe choice.

Clicking “Show Certificate” exposed the certificate chain—information which most users don’t know how to use—and included a message that was more specific about the error.

In some cases, those messages were confusing or downright misleading. For self-signed certificates, which a normal user should never use, the message said, “this certificate has not been verified by a third party,” which does not communicate the risk of using a completely untrusted certificate.

Safari had been using that UI since at least version 7, released in 2013. At that time, the effectiveness of security UI was rarely studied and not well understood. It is only in the last few years that we have seen data-driven improvements in the security UI of web browsers.

Creating Better Warnings

Safari 11’s new UI bears a strong resemblance to Google Chrome’s:

Safari 11 uses a full-page error, similar to what Chrome and Firefox have been using, and borrows a few key design features.

Chrome redesigned its  certificate warning UI in 2015. Supported by an extensive research study, Google’s engineers found that an “opinionated design”—which visually prioritizes the desired choice—led to a significant increase in adherence to the warning. Google’s redesigned UI, which premiered in Chrome 37, had an adherence rate of 58 percent, compared to the previous design’s 31 percent.

Chrome and Safari 11 use opinioned design in the same way: both hide the undesired choice (proceeding past the warning).  You first have to click a button to reveal the option to proceed. In Chrome the button is named “Advanced,” and in Safari 11 it’s “Show Details.” The option to proceed past the error is then a small and visually undistinguished hyperlink.

Safari’s new error page states, “You should go back to the previous page.” This non-technical advice gives the user clear guidance on what they should do in most circumstances.

Safari 11’s certificate warning UI should yield similar improvements to what Google Chrome’s team achieved. By improving adherence rates, Apple is helping users stay safe, and combat “warning fatigue,” a dangerous effect of poorly designed warnings.

Warning fatigue occurs when a user sees a warning too often and believes it is unimportant or incorrect. In addition to frequency, warning fatigue can also occur when a user does not understand what a warning message means.

Safari 11 is available now through the App Store for macOS versions El Capitan (10.11.6) and newer.

The new European Union General Data Protection Regulation (GDPR) deadline is May 25, 2018, and despite that date quickly approaching, research shows many companies still aren’t ready. If they remain non-compliant, companies will face a fine up to 4 percent of annual turnover or €20 million (whichever is greater) per breach or issue related to lack of compliance.

With changing regulations, we see that digital security is no longer just an IT issue, it’s a business continuity requirement. You can be proactive and take steps today to become compliant and avoid fines.

Protecting Privacy, Data, and Rights for EU Residents

The main purpose of the GDPR is to protect the personal data for EU residents. The regulation aims to help everyone know:

• Why certain information needs to be provided
• How personal information is being used
• Who has access to sensitive information
• That each individual has control over their data

The territorial scope for GDPR is the biggest change. At first, GDPR compliance was only applied to organizations located within the EU, but new requirements extend the scope to all companies processing personal data of EU residents—despite the location of the company who is processing or handling the data.

The Cost of Data Breaches

Breaches that result in data exposure cause irreparable damage to companies’ reputation and are costly with incident response, remediation, impact assessment, insurance, legal fees, and settlements all associated.

Once GDPR goes into effect, breached companies will face additional fines determined on a tiered level, according to the type of breach, amount and type of data exposed, notification, remediation, and response. As mentioned previously, such fines will be up to €20 million or 4 percent of organization’s annual turnover.

Main Causes of Data Breaches

According to Verizon’s 2016 Data Breach Investigation Report, the most common causes of breaches were:

• Lack of encryption
• Lack of security when handling confidential information
• Unpatched systems and lack of system segmentation
• Lack of consent and permissions management, generating back ways to access information
• Lack of strong log-in credentials
• Lack of identification of devices accessing network

In only 4 percent of the reported data breaches, encryption was used, and that data rendered useless to cyber criminals. Strong log-in credentials and using PKI certificates for multi-factor authentication in critical systems have also proven to be effective in increasing security, preventing unauthorized access, and avoiding data exposure even in the event of breaches.

How DigiCert Can Help with GDPR Compliance

The DigiCert enterprise certificate management platform, CertCentral®, can help you and your company streamline digital certificate management and make sure each certificate meets security requirements, by ensuring you’re using the the most up-to-date algorithms, preventing vulnerabilities and the use of weak of obsolete cyphers.

Using the DigiCert platform, you can order and manage:

• Public SSL certificates for public domains
• Private SSL certificates for internal domains, systems, hosts, and endpoints

Client certificates for email signature, email encryption, user authentication, and device authentication

CertCentral integrates by default with the DigiCert Certificate Inspector. The agent can be deployed externally and internally to build an inventory of all your certificates, despite issuing CA, including self-signed certificates (e.g., Microsoft CA). The agent scans your network to find vulnerabilities related to certificates and endpoint configurations.

The DigiCert RESTful API allows you to fully integrate processes, automate provisioning and management, and customize solutions to fit your needs.

Different from other CAs, we aren’t a certificate factory—we are a security partner to our customers, helping them secure their data, as well as their customers’ data.

Act today to meet the GDPR compliance deadline and save your organization stress and costly fines. Protect your most valuable assets: your customers and their data.

In our previous interview with Darin Andrew, Senior PKI Architect at DigiCert, we discussed the differences between public and private PKI. We established that most enterprises use a hybrid PKI solution.

That said, you have two options for implementing your private PKI: (1) use a hosted solution from a certificate authority (CA) or (2) build your own internal CA. Because people often wonder about the costs and benefits of each, we asked Darin to break them down for us.

Let’s say I’ve decided to create a private root—should I use a hosted or internal CA?

DA:

It’s possible to set up your own internal CA. The real question is, does it make sense for your organization to put the resources into building that internal CA? This has to be looked at on a case-by-case basis.

The goals of the average company don’t revolve around creating a robust PKI solution. If you’re a commercial CA, that’s your number-one goal. But engineers in most companies have more immediate goals, like keeping their sales force or manufacturing lines going.

Often, a hosted solution can give you everything you need. Then, your engineering team can focus on your organization’s most critical projects. For some companies, it makes sense to build an internal CA. Unfortunately, I often see companies building internal CAs not because it’s what’s best for their company, but because they have misconceptions about hosted solutions.

What are some of those misconceptions about hosted solutions?

DA:

In short, the common misconceptions revolve around cost, capability, and flexibility.

Many have only dealt with a CA to purchase publicly trusted SSL certificates for their web pages. Because this is their only reference point, they assume private certificates will have the same per-cert costs as publicly trusted certificates—this isn’t the case.

Issuing a private certificate with a hosted CA is usually a fraction of the cost of a publicly trusted certificate with that same CA. We almost always get the per-cert cost for private certificates below what our customers were projecting.

Another common misconception many have is that they won’t be able to accomplish the same goals with a hosted solution. For example, you might wonder whether you can automate certificate issuance with a hosted solution. Many commercial CAs have tools, like APIs, for automating certificate management. Before you choose a commercial CA, check out their platform and tools.

Many also think a hosted CA will limit them to certain certificate profiles. They think they’ll only get certificate profiles that are approved by the CA/Browser Forum. Because these are private certificates we’re talking about, DigiCert will provide any certificate profile you need. They don’t have to be SSL certificate profiles. They don’t even have to be X.509.

So, how do I decide if it makes sense for my organization to build an internal CA?

DA:

The first thing to consider is scale. How do you determine the scale of your PKI?

In our first interview, we talked about looking 5 to 10 years into the future. Companies often build an internal CA based on today’s needs, only to find that it’s not sufficient for tomorrow’s needs.

For example, let’s say your current need for an internal CA is to issue authentication certs to your laptops and phones, so they can authenticate into your wireless.

Five months down the road, you might realize you need to set up certs for all your internal servers. You might want certificates to be issued to all servers automatically through an API.

Now, you’re creating an API interface, which is yet another project. What started as a small project is now ballooning into a resource-intensive one.

Don’t be fooled by the scope of the project today—think long term. It’s hard to guess what you’ll need 5 to 10 years from now. An established commercial CA is a good resource for this because it has worked with a broad range of enterprises. A commercial CA has a view into how those PKIs have scaled over the years.

What are some of the costs of creating an internal CA?

DA:     

Often I see that the cost of personnel is left out of creating an internal CA. I’m not just referring to the cost of hiring additional personnel to build and manage the internal CA, but also the opportunity cost of your engineering team’s time.

Your engineering team likely has a bunch of other responsibilities for security and maintaining infrastructure. Things like email servers, wireless, penetration testing, audits, risk assessments, and the list goes on. They have a lot on their plates. Creating an internal CA could take them away from other important tasks. 

Another thing people forget is that issuance is only one piece of the puzzle. It’s great to keep in mind other crucial pieces, like revocation.

Look, you could end up spending half a million dollars to build an internal CA, but it really depends on the scope and scale of your project and your projected future needs. For the goals of some companies, it could cost less or more.

Instead of putting dollar amounts on the costs, it probably makes more sense just to list out the items to consider. There’s just no way to put a dollar amount to it, because there’s so much variation from company to company. That said, the following list will help you by identifying whether you need each line item and evaluating the cost of each for your business.

Darin broke down the cost considerations for us during the interview. They break down into six main categories:

1. Hardware, software, and licensing
2. PKI expertise
3. Training
4. Certificate policy (CP) and certificate practices statement (CPS)
5. Auditing against certificate policy
6. Vulnerability testing

For the purposes of this post, we will focus on hardware, software, licensing, and personnel. Here’s a more detailed look at what those costs include in each category:

Hardware, Software, & Licensing

• CA server including redundant CA server
• Online Certificate Status Protocol (OCSP) and Certificate Revocation List (CRL) distributed services for redundancy and high availability, as well as fast response times
• Firewalls, segregated networks, and dedicated rack space
• Storage mechanism for offline root and backup of offline root—HSMs required
• Signing HSMs

Personnel

• PKI authorities and administrators
• Developer resources to write interface used to request/revoke certs (if needed)
• Audit staff
• Regular training of staff who have PKI responsibilities (certifications, conferences, etc.)

Note: Avg. industry salary: $120-$200k per individual

DA:

Of course, these aren’t all the possible cost considerations, but we’ve given you some of the key costs to get you started. The best thing you can do in this position is reach out to a PKI engineer at an established commercial CA. They will help you evaluate your specific PKI architecture needs, which will give you a detailed and accurate cost projection.

If you’re considering a hosted solution, make sure the commercial CA you’ve chosen can give you the customization you need.

In our next post, we’ll tackle how to automate certificate management. For now, here are your takeaways:

In our first interview with Darin Andrew, Senior PKI Architect at DigiCert, we learned to keep the next 5–10 years in mind when making decisions about PKI architecture. We even learned about three ways top enterprises are using PKI to enhance cybersecurity.

Now, we ask Darin about the difference between public and private PKI, which is best for different use cases, and how some of the top enterprises have built PKIs that scale successfully. We start from square one—discussing the purpose of a root certificate.

What’s a root certificate?

DA:

Public Key Infrastructure (PKI) is binding an identity to the public key through a signing process.

That signature is performed by a root (or with an intermediate that chains up to the root). That’s how you identify if a certificate is valid, and whether you want to trust it.

If you possess the public key of the root that signed the certificate, then you can know that the identity bound to the public key is valid and can be trusted. This is all because the certificate was issued by the root.

What’s a public root? 

DA: 

The technology used for signing a certificate is the same whether signing with a private or public root. We’re not changing the cryptography or the signature. We’re simply saying that a publicly trusted root is already distributed out to browsers, operating systems, phones, etc. Browsers, like Chrome and Firefox, have root stores where they keep a list of the roots they trust.

A private root differs from a public root because private roots aren’t already distributed to the trust stores of major browsers and operating systems. A private root is created by a company or a CA, and won’t be included in the list Google and Mozilla have in their browser trust stores.

It’s a private root because it’s trusted by whatever systems the company wants to distribute that root to internally. They can distribute that root to their servers or a select number of their servers, phones, desktops, and laptops. They can issue certificates from that private root that will be trusted by whichever system they deliver that root to for checking if certificates are valid.

Because the technology behind public and private roots is the same—the certificate looks the same and the same signature hash algorithm can be used to sign the certificate—the next question would be, when do you use a private root versus a public root?

When should you use a public root versus a private root?

DA:

A private root is useful for internal operations. However, when you’re talking about a public-facing web page, you need a certificate issued from a public root.

Think about your website. When users visit your site, does their browser possess the root? With a private root, the answer depends on whether it’s being accessed from a computer the organization manages or not.

The browser can have the private root if you’ve distributed your private root to that device. If the certificate has been issued by a private root that has been added to the browser’s trust store, the browser will trust it when it connects to the web page.

But what happens if this is a public web page that anyone in the world can hit? Unless you’ve distributed your private root to every single device that’s used to visit the page (which isn’t possible), users will receive a warning message saying the root that issued the certificate isn’t trusted.

Browsers are giving severe warning messages these days. Either the users won’t be able to visit the page, or they’ll be forced to change their settings to make the connection. That’s not a good place to be in.

How would the private/public root scenario influence something like email signing?

DA:

If you’re sending email to someone within your own company, you sign your email using a certificate issued from the private root—that works. The recipient checks the signature, sees it was issued by the private root that’s already on their computer, and they say, “That certificate is valid.”

But, what happens when you send that email to someone from another organization that doesn’t have your private root? They’ll see a message that says the signature is not valid.

This automatically happens in Outlook, for example. Outlook checks to see if the root that issued the certificate is in the root store of the operating system. When it sees that it’s not, Outlook displays a message saying that the signature is not valid.

Using a private root for email doesn’t make much sense. The reason you sign email is to assure the person on the other end that they can trust that the message was sent from you and wasn’t altered.

But, when you send email to another organization (which is the nature of email), if you’re using a private root, this results in an untrusted message. You’ve now destroyed the purpose for signing the email. This is an instance where you need publicly trusted certificates issued from a public root.

In short, a private root will help you secure internal operations. But when you’re sharing information with entities outside your organization—like signing an email—you need a public root that’s distributed to browsers and operating systems.

So, in what scenarios would a private root be useful?

DA:

Authentication of internal services is a strong use case for private roots. For example, a private root is useful for authenticating connections into your virtual private network (VPN), internal Wi-Fi, wiki pages, or other services that support multi-factor authentication.

In all those cases, you control the server instance that’s checking the validity of the certificate, so a private root will work great. Your internal operations team can specify your own private root as the issuer of certificates, and when validity is being checked, it can see that it was issued by your own private root.

Using a private root has its benefits over public roots. If it’s a dedicated private root for your organization, only your team can issue certificates off that root. No one else can issue certificates off that private root. Certificates issued from a private root have more flexibility for certificate profiles and subjects named in the certificates.

The benefits of a private root for authentication boil down to control. If you have a private root that’s dedicated to you, you have more control over the issuance process, certificate profiles, and subjects named in the certificates. Because you have more control, you know with more certainty that you’re the only one who has the rights to issue certs from it.

Do most enterprises have a public or private PKI?

DA:

It’s most common for enterprises to use a hybrid of the two. For example, a company might use a public CA to issue certificates for its public-facing website. Then, for authenticating connections to its internal services—like a VPN or wiki—that same company might set up a private root where they can issue certificates.

Let’s say I’ve decided to set up a hybrid PKI solution—what’s next?

DA:

Next, you’ll want to decide whether you use a hosted solution for your private PKI, or build your own internal CA.

Often, people think public PKI is hosted and private PKI is not hosted—this isn’t the case. Public and private PKI can both be hosted. The question is whether you have an internal CA or use a hosted CA for your private PKI.

In our next interview with Darin, we’ll dive into the considerations of whether to use a hosted or internal CA solution.

For now, here are your takeaways for making decisions between public and private PKI: