+1-408-638-9323 info@revocent.com
03 Feb16:56pm

Why Self-Signed Certificates Are Evil

Why Self-Signed Certificates Are Evil

Self-signed X.509 digital certificates are often used inside enterprises of all sizes on devices and application servers which use HTTPS.  Its often so common place in some enterprises that its easy to forget self-signed certificates are evil.  Maybe not evil in a deliberate sense, but certainly in an effective manner.  Self-signed certificates often lurk in an enterprise and are neglected until used to compromise security which results in serious breaches and damages.

Before we discuss why lets do some level setting and define what a self-signed certificate is.

What Is a Self-Signed Certificate?

A self-signed certificate is a X.509 certificate signed by the same authority as the subject of the certificate.  That is the certificate subject is the same as the certificate issuer.  Non self-signed certificates are signed and issued by a trusted Certificate Authority (CA) which typically involves a vetting process and issuance process to ensure the certificate is being legitimately requested by an authorized user.  Self-signed certificates in contrast, can be created by anyone and can represent any subject entity.

Self-signed certificates can be created using the OpenSSL command line interface (CLI) available for most Linux, MacOSX, and Windows platforms.

What Are Certificates Used For?

Certificates are most commonly consumed by web browsers and other client applications which use HTTPS.  The HTTPS protocol uses Transportation Layer Security (TLS), formerly known as SSL, to encrypt the data being sent over a network.  An X.509 digital certificate is required on the HTTPS server to validate the identity and create the encryption keys for the session.

Certificates can be used for many other purposes, but the focus of this discussion is on HTTPS/TLS.

The Evils of Self-Signed Certificates

The purpose of a X.509 digital certificate is to represent a validated subject identity.  This can be a computer, person, or most any arbitrary entity type.  The value of a certificate is only as valuable as the trust of the issuer.  When a Certificate Authority (CA) creates a certificate it is typically done using some kind of authentication and vetting process.  This might be validating an Active Directory user or computer for an enterprise certificate or some kind of vetting process employed by commercial public CAs.

When you use a self-signed certificate for TLS you have little actual protection.  It allows TLS to work but it bypasses most of the protection offered by TLS in the first place.  Its like building a castle, outfitting it with Kevlar walls, automatic machine guns, and blast proof doors with an lock made from a sheet of paper.

Let’s explore some scenarios that illustrate the dangers of self-signed certificates.

Evil Scenario #1

Let’s say you have an internal enterprise application which provides a web over HTTPS/TLS interface.  If you use a self-signed certificate for this application server you are exposing all that confidential data to potential unauthorized disclosure and compromise.  Someone on your network could create their own proxy server with their own self-signed certificate and then intercept and view all the data as it flows to the actual application server.

This can occur because the browser communicating with the application server will not be able to verify the certificate.  The browser will present the user with a stern warning saying the site is unsafe.  However, it says the same thing when the actual application server responds with its own self-signed certificate.  Users have no easy means of telling if the actual application server is responding or if they are talking to the interceptor proxy.

Evil Scenario #2

Building on the previous scenario, imagine if the intruder proxy not only views all the data, but also subtly changes the data.  If the application server is providing status on say the temperatures of a fab machine or a nuclear reactor.  The proxy could change the results in the data being returned to the user to provide a false view.  This could mask a coordinated attack on those devices which could result in the destruction of millions of dollars of equipment and possible much human life loss.

Evil Scenario #3

If you are using self-signed certificates on even a few servers you will likely be telling your users that if the browser says a site is unsafe due to a self-signed certificate, that they should click the right button to bypass the warning and proceed.  Even experienced IT staff will eventually become use to this that they will bypass the warning every time.

So now imagine a bad actor who installs multiple proxies across your network.  Suddenly it’s not just one compromised application server but all application servers with self-signed certificates.

Congratulations you have now trained your users to bypass a critical component of your enterprise security.

Evil Scenario #4

It gets worse.  Maybe you have your “most valuable” application servers configured with CA issued certificates and only use self-signed certificates on “low risk” servers used for testing or making coffee.  What if some of the intercepted data from the self-signed application servers can be used to compromise user or application accounts on the “most valuable” application servers?  The intercepted data could be usernames and passwords or could be related data that a hacker could use to guess passwords or execute a phishing attack to trick users into compromising their accounts.

Think your test servers are low risk and self-signed certificates are perfect?  Ask yourself how many of your users use the same username and password everywhere?  Most likely the number is fairly high.

Once you have leaks in your dam it will quickly crumble under attack from even a modestly skilled intruder.

Why Do People Create Self-Signed Certificates?

Many people create and use self-signed certificates because its fast and easy.  Running a few OpenSSL commands to create a certificate can be done in a few minutes but requesting a certificate from the enterprise PKI may involve multiple people and take days or weeks to complete.

Many enterprises have a Microsoft ADCS based PKI which integrates well with Windows systems, but requires a long, manual process to create certificates for Linux and MacOSX.

A solution like CertAccord Enterprise by Revocent can automate the certificate creation and renewal process on Linux and MacOSX by integrating with Microsoft ADCS.  The CertAccord agent on Linux and MacOSX can actually create certificates from Microsoft ADCS faster than a manual OpenSSL self-signed certificate can be created.  Even better, the certificate is fully managed and will be automatically renewed.

When Should Self-Signed Certificates Be Used?

Almost never!  The best place for a self-signed certificate is when you are creating a Root Certificate Authority for your enterprise.  By its very nature the Root certificate must be self-signed.

Summary

Self-signed certificates are a danger to any sized organization.  The longer you go without addressing this the more risk you assume and the harder it is to address over time.

The best course of action is to plan, build, and implement an enterprise Public Key Infrastructure (PKI) with a sound process and consistent best practices.

CertAccord Enterprise by Revocent provides a fast, easy certificate automation platform you can quickly bold-on to your existing Microsoft ADCS environment to automate certificates on Linux, MacOSX, and Windows.

 

Comment • Read More
13 Aug00:57am

How To Create Trusted X.509 Certificates On MacOS X

How To Create Trusted X.509 Certificates On MacOS X

Creating trusted enterprise certificates on Apple’s MacOS X has never been easy, but it can be.

In the traditional process you have to create a private key, create a Certificate Signing Request (CSR), submit the CSR to a Certificate Authority (CA), retrieve the issued certificate, install it, and then remember to renew it before it expires.  Not easy.  There are lots of opportunities for human error and you have to be very disciplined.

Sure you can skip some of the steps by creating a self-signed certificate, but it won’t be trusted in your enterprise environment without each software component on each system being updated.  That only makes life harder and your environment less secure.

CertAccord© Enterprise solves this problem.  It makes creating and installing trusted enterprise certificates easy by automating nearly all of the process.  Let’s examine the traditional process of certificate creation on MacOS X and the easy CertAccord process.

Traditional Certificate Creation

The traditional process of creating a trusted certificate on MacOS X is based on using the OpenSSL command line tool built into MacOS X.

STEP 1 – Install OpenSSL

To get started you need to see if you already have OpenSSL installed.  It’s typically provided by default.  To verify open a shell and run:

Shell
1
openssl version

If openssl is installed you will see the OpenSSL version information.  If it’s not installed, you’ll get an error like “Command not found”.

STEP 2 – Create Key Pair

The private and public key pair is needed to sign the CSR.  To create the key pair you need to decide upon a cryptographic algorithm (RSA is the most common) and the bit-size of the key.  In this example we will use create an RSA 4096 key (current best practice) and store it in the file my.key:

Shell
1
openssl genrsa -out my.key 4096

STEP 3 – Generate CSR

Now we will create the Certificate Signing Request (CSR):

Shell
1
openssl req -new -key my.key -out my.csr

This command will save the CSR to the my.csr file. You will be prompted to fill-in various fields:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:California
Locality Name (eg, city) []:San Jose
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Acme Inc
Organizational Unit Name (eg, section) []:IT
Common Name (e.g. server FQDN or YOUR name) []:www.my.com
Email Address []:it@my.com
 
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

STEP 4 – Submit CSR To CA

Take the CSR file (my.csr) and submit it to your enterprise Certificate Authority. How you do this depends on the CA you have. If you have a Microsoft CA, then a user with administrator access to the Microsoft CA has to take the CSR and submit it using the CA Manager.

Once a certificate is created from the CSR you should then receive the certificate file and typically a CA trust file.

STEP 5 – Install Certificate

Copy the certificate file and CA trust file to your MacOS X system.  How you do this will depend on the CA product used and your internal process for certificate creation.

If the certificate is a web server certificate for Apache HTTPD, then you copy the certificate file, the certificate private key (my.key), and the CA trust file to the appropriate directories for your MacOS X / Apache configuration.

You then need to edit the appropriate Apache HTTPD configuration file to specify the certificate file, private key file, and CA trust file.

CertAccord Enterprise Certificate Installation

Creating and installing certificates with CertAccord is simple, easy, and doesn’t take a PKI expert.

For this article we are going to assume your enterprise PKI experts have already installed the CertAccord Enterprise Server.

STEP 1 – Install CertAccord Enterprise Agent

If you don’t already have the CertAccord Agent installed, you can install it by copying the CertAccord Agent installer to your MacOS X system.   Then run the installer:

Shell
1
2
3
4
sudo hdiutil attach /tmp/cmbagent-version-platform.dmg
sudo '/Volumes/CertAccord Installer version/cmbagent/version.app/Contents/MacOS/installbuilder.sh' \
   --mode unattended
sudu hdiutil detach '/Volumes/CertAccord Installer version'

This command will install the Agent into the default location of /Applications/CertAccord.

STEP 2 – Register Agent

Shell
1
2
3
export PATH=/Applications/CertAccord/bin:$PATH
cmb register server=<em>myserver
</em>

Change myserver to be the hostname of the CertAccord Enterprise Server.

When you run this command, the Agent will download the CA trust information from the server, generate a private key locally (configured to adhere to the policies given by the server), and then submit the registration request to the server.

STEP 3 – Create Certificate

To create a web server certificate for use with Apache HTTPD or other web server, run the following command:

Shell
1
cmb cert create purpose=webserver

This command will automatically create a CSR, submit it to the enterprise CA, and install the certificate once issued. This is all done using the PKI policies configured on the CertAccord Enterprise Server and your enterprise CA. No knowledge of these policies or configuration requires are needed by the MacOS X system administrator when running this command.

Here is example output:

1
2
3
4
5
6
7
8
9
10
Creating Certificate PURPOSES: [WebServer]
Created certificate 634RJ65d [SUBJECT: "dune.contoso.com" PURPOSES: WebServer EXPIRES: Jul 14 2021 13:52:14 PDT]
Saved certificate 634RJ65d [SUBJECT: "dune.contoso.com" PURPOSES: WebServer EXPIRES: Jul 14 2021 13:52:14 PDT] to AgentProfile
Apply Certificate 634RJ65d [SUBJECT: "dune.contoso.com" PURPOSES: WebServer EXPIRES: Jul 14 2021 13:52:14 PDT]
Exported Certificate 634RJ65d [SUBJECT: "dune.contoso.com" PURPOSES: WebServer EXPIRES: Jul 14 2021 13:52:14 PDT] to /var/cmb/cert/dune.magnicomp.com-webserver.crt
Exported PrivateKey Grq8jB3h [RSA 2048] to /var/cmb/cert/dune.contoso.com-webserver.key
Applying certificate to Apache HTTP Web Server: ID: 634RJ65d PURPOSE: WebServer
COMMAND [/usr/sbin/service apache2 reload] ran successfully
Reloaded Apache HTTP Web Server
Apply certificate to Apache HTTP Web Server: ID: 634RJ65d RESULT: Succeeded

The output shows that a certificate was created, saved to the local Agent database, and a copy of the certificate was exported to /var/cmb/cert/dune.contoso.com-webserver.crt. The Apache HTTPD server was also reloaded so that it re-read its configured certificate files.

A few key take-aways:

  1. Using the CertAccord Agent required no prior knowledge of the enterprise PKI policies for keys or certificates.
  2. Because the certificate was created by the enterprise CA and is not self-signed, the certificate is automatically verifiable by any application in the enterprise.
  3. The Agent manages the life-cycle of the certificate.  That means it will automatically renew the certificate without any human intervention.

Summary

The CertAccord Enterprise Agent is a much easier and simpler means of creating trusted certificates on MacOS X.  It can lower IT costs through automated certificate creation and life-cycle management, improve security by reducing errors in creation and renewals, and be implemented as a bolt-on to your existing enterprise PKI.

More Information

 

Comment • Read More
13 Aug00:47am

CertAccord – How To Create Trusted Certificates From Command Line On MacOS X

CertAccord – How To Create Trusted Certificates From Command Line On MacOS X

Creating a trusted X.509 certificate on Apple’s MacOS X (as well as Linux) is fast and simple using CertAccord Enterprise.  Most any IT system administrator can create certificates without having to be a PKI expert.

This article shows you how to create a trusted X.509 certificate from the MacOS X command line (bash prompt) in just a few minutes.  Once the certificate is created it will be installed locally and managed automatically (including automatic renewals).

Prerequisites

The CertAccord Enterprise Server must be installed and configured to access your enterprise Microsoft Certificate Authority.

STEP 1 – Install CertAccord Enterprise Agent

If you don’t already have the CertAccord Agent installed, you can install it by copying the CertAccord Agent installer to your MacOS X system.   Then run the installer:

Shell
1
2
3
4
sudo hdiutil attach /tmp/cmbagent-<em>version</em>-<em>platform</em>.dmg
sudo '/Volumes/CertAccord Installer <em>version</em>/cmbagent/<em>version</em>.app/Contents/MacOS/installbuilder.sh' --mode
unattended
sudu hdiutil detach '/Volumes/CertAccord Installer <em>version</em>'

This command will install the Agent into the default location of /Applications/CertAccord.

STEP 2 – Register Agent

Shell
1
2
export PATH=/Applications/CertAccord/bin:$PATH
cmb register server=myserver

Change myserver to be the hostname of the CertAccord Enterprise Server.

When you run this command, the Agent will download the CA trust information from the server, generate a private key locally (configured to adhere to the policies given by the server), and then submit the registration request to the server.

STEP 3 – Create Certificate

To create a web server certificate for use with Apache HTTPD or other web server, run the following command:

Shell
1
cmb cert create purpose=webserver

This command will automatically create a CSR, submit it to the enterprise CA, and install the certificate once issued. This is all done using the PKI policies configured on the CertAccord Enterprise Server and your enterprise CA. No knowledge of these policies or configuration requires are needed by the system administrator when running this command.

Here is example output:

1
2
3
4
5
6
7
8
9
10
Creating Certificate PURPOSES: [WebServer]
Created certificate 634RJ65d [SUBJECT: "dune.contoso.com" PURPOSES: WebServer EXPIRES: Jul 14 2021 13:52:14 PDT]
Saved certificate 634RJ65d [SUBJECT: "dune.contoso.com" PURPOSES: WebServer EXPIRES: Jul 14 2021 13:52:14 PDT] to AgentProfile
Apply Certificate 634RJ65d [SUBJECT: "dune.contoso.com" PURPOSES: WebServer EXPIRES: Jul 14 2021 13:52:14 PDT]
Exported Certificate 634RJ65d [SUBJECT: "dune.contoso.com" PURPOSES: WebServer EXPIRES: Jul 14 2021 13:52:14 PDT] to /var/cmb/cert/dune.magnicomp.com-webserver.crt
Exported PrivateKey Grq8jB3h [RSA 2048] to /var/cmb/cert/dune.contoso.com-webserver.key
Applying certificate to Apache HTTP Web Server: ID: 634RJ65d PURPOSE: WebServer
COMMAND [/usr/sbin/service apache2 reload] ran successfully
Reloaded Apache HTTP Web Server
Apply certificate to Apache HTTP Web Server: ID: 634RJ65d RESULT: Succeeded

The output shows that a certificate was created, saved to the local Agent database, and a copy of the certificate was exported to /var/cmb/cert/dune.contoso.com-webserver.crt. The Apache HTTPD server was also reloaded so that it re-read its configured certificate files.

Summary

A few key take-aways:

  1. Using the CertAccord Agent required no prior knowledge of the enterprise PKI policies for keys or certificates.
  2. Because the certificate was created by the enterprise CA and is not self-signed, the certificate is automatically verifiable by any application in the enterprise.
  3. The Agent manages the life-cycle of the certificate.  That means it will automatically renew the certificate without any human intervention.

References

Comment • Read More
13 Aug00:03am

MS-WCCE Automated Solution for MacOS X

MS-WCCE Automated Solution for MacOS X

Windows systems have long supported Microsoft Windows Client Certificate Enrollment (MS-WCCE) which provides automatic X.509 certificate deployment and renewal with Microsoft Active Directory Certificate Services (ADCS).  Apple’s MacOS X systems have no MS-WCCE support or any other built-in automated integration with ADCS.  This is a key reason we created CertAccord Enterprise.

Much like MS-WCCE on Windows, CertAccord Enterprise on MacOS X (as well as Linux) enables X.509 certificate creation using Microsoft ADCS.  Everything is done automatically with no OpenSSL or web forms or other manual processes.

Create Certificate In One Simple Command

This is all it takes to create a certificate using CertAccord on a Mac system:

1
cmb cert create purpose=webserver

This simple command will send a request to Microsoft ADCS to create an X.509 certificate and then place it on the local filesystem.  No OpenSSL is used.  You don’t have to create a Certificate Signing Request (CSR) and then cut-and-paste it into some web form.

Automatic Certificate Renewals

One of the great features of MS-WCCE is automatic certificate renewals.  How many times have you had manually created certificates on MacOS X expire and take down a key service?  Once is too many.

Any certificate that CertAccord Enterprise creates will be automatically renewed before it expires.  No more manual processes to track renewals.

Active Directory Authentication

Since MS-WCCE is built into Windows it uses Active Directory (AD) to authenticate certificate requests.  Wouldn’t it be nice if you could do that on MacOS X?

CertAccord Enterprise integrates with AD.  Whenever you request a certificate creation from MacOS X CertAccord will prompt for AD username and password.  This credential information will be used to validate the user is allowed to create certificates using CertAccord’s Role Based Access Control (RBAC).  Best of all, the CertAccord AD integration is done purely through CertAccord and does not require the local MacOS X system be domain joined or have its system level authentication integrated with AD.

Easy Installation

CertAccord Enterprise is designed to quickly and easy install into your existing Microsoft PKI environment.  Typical installs take a few hours.  You don’t have to major any significant changes to your Certificate Authorities or Active Directory configuration.  There is no change to your MacOS X system authentication.

Next Steps

Please contact us to see a demo of CertAccord Enterprise and learn how you can bring MS-WCCE features to your MacOS X and Linux systems quickly and easily.

 

Comment • Read More
12 Aug23:07pm

MacOS X Certificate Auto Enrollment With Microsoft CA

MacOS X Certificate Auto Enrollment With Microsoft CA

There is no free MacOS X “client” which provides Auto Enrollment or integrates with the Microsoft PKI like the one built into Microsoft Windows.   However, there are commercial options which provide very similar abilities, one in particular which is actually easy to install, use, and won’t blowup your budget.

Many commercial and government enterprise organizations leverage MacOS X for laptops, desktops, and servers which often require an X.509 trusted certificate.  Typically the need is for an SSL/TLS Server Authentication certificate commonly known as a web server certificate or a Client Authentication certificate.  These certificates are typically used for user and device authentication and other applications such as connecting to enterprise VPN.

The most common Public Key Infrastructure (PKI) in these same organizations is the Microsoft Enterprise Certificate Authority (CA).   There are no free MacOS X options which provide automated integration with the Microsoft CA.  This historically leaves organizations the choice of using “free” MacOS X tools combined with a complex manual process or purchase one of the very large and complex commercial products on the market.

There is a better solution that doesn’t have all the downsides of the “free” solution and doesn’t require substantial budget like the older monolithic commercial solutions.

Free Doesn’t Mean Low Cost

The “free” MacOS X tools approach typically involves IT admins using the OpenSSL command line to create a private key and certificate signing request (CSR), email the request to the Microsoft PKI Admin, receive back the certificate, and install the certificate and key properly.  Then you also have to have some kind of out-of-band reminder to to repeat this process before the certificate expires.

This might be manageable for a dozen or so systems, but this scales very poorly.

The usual result are certificates with either too long an expiration and/or certificates which expire without being renewed.  Using long, multi-year expiration times is far from ideal because the longer a certificate is valid, the more it is susceptible to weakened cryptography.  Using shorter expiration times shortens the exposure to susceptible cryptography, but comes at the cost of more frequent certificate renewals.

IT admins are human.  They forget things.  One thing they often forget is to renew manually managed certificates.  This leads to service outages and unhappy customers.

Even if your IT admins have the memory of an elephant and the discipline of a Tai Chi Master, the labor costs of creating and managing large numbers of certificates in this manner is huge.

Prepare For Assimilation

There are several behemoth commercial products on the market which can automate the certificate process.  However, these products require “total assimilation” similar to the approach of the fictional The Borg.

You have to integrate each MacOS X system with Active Directory and switch your user identification authentication over as well.  This requires massive changes to existing MacOS X and Microsoft infrastructure.

The result is implementation time-frames of 3 months to more than 3 years and have a price tag that starts at $250K for an “entry level” implementation to $1M or more for large organizations.

That’s not easy and it’s not cheap by any means.

The Easy Way

Revocent developed CertAccord Enterprise to solve these problems. CertAccord Enterprise provides a MacOS X (also Linux, Unix, and Windows) Client for auto enrollment with the Microsoft PKI Certificate Authority.

It is designed to be easy to use by MacOS X admins who just want to be able to run a simple command to “create web server certificate” and then have the certificate managed (renewed) through-out its life-cycle.   The certificate creator gives the purpose of the certificate without having to know what the company PKI configuration policies are to create a private key or certificate.  That is all configured by the enterprise PKI experts.

The Microsoft PKI administrators use nearly all the same tools and interfaces to manage Certificate Templates (policies) with the addition of the CertAccord Enterprise Console Management web GUI.  The Console is where MacOS X device registrations are controlled and where certificate Templates (policies) are “connected” to CertAccord for use.

It’s easy to install because it’s designed as a “bolt-on” to your existing Microsoft PKI and MacOS X infrastructure.  You don’t integrate your MacOS X systems with AD so it’s a simple installation.

You don’t have to spend a year implementing it and it won’t cost you most of your annual budget.   It’s just easier.

References

 

Comment • Read More
04 Apr01:09am

Configuring Apache HTTPD TLS Using Microsoft ADCS Certificates

Configuring Apache HTTPD TLS Using Microsoft ADCS Certificates

This quick guide will give you step-by-step instructions on how to configure Apache HTTPD on Linux with TLS (SSL) using an x.509 certificate issued from a Microsoft Active Directory Certificate Services (ADCS) PKI environment.  We will cover two methods of achieving this goal both of which have very different levels of complexity and real cost.

A common method used by many, but not necessarily the best is a manual process using OpenSSL which is built-in to most Linux distributions.   The second method we will cover is using CertAccord Enterprise to create and renew certificates automatically using Microsoft ADCS.

Background

Transport Layer Security (TLS) is the successor to Secure Sockets Layer (SSL).  It provides validation of a server’s identity and encryption of all communications between the client (web browser, etc) and server (Apache HTTPD, etc).  TLS requires that a server have an x.509 certificate.  These certificates can be self-signed or issued by a trusted Certificate Authority (CA).  Use of self-signed certificates is insecure and rarely the best option.

In many organizations Microsoft ADCS (sometimes referred to as Windows PKI or Windows Certificate Authority) provides the Public Key Infrastructure (PKI) for certificate issuance.  Apache HTTPD is often used in such environments to provide web services.

Conventions

We will use the name “www.contoso.com” in our examples.  When you follow these steps change this name to your server’s name.

METHOD 1 – OpenSSL

The first method we will cover is using OpenSSL.  OpenSSL is a set of command line tools and libraries that are part of nearly every Linux distribution.  OpenSSL provides the ability to create Certificate Signing Requests (CSR) which must be manually transported to Microsoft ADCS and submitted.  Once ADCS issues the certificate it must be manually transported back to the target linux system.

It is also important to remember that certificates expire and using this method you must manually track when your certificates expire.  Prior to expiration you have to perform the same manual CSR process.

STEP: Install OpenSSL

Most Linux distributions already have OpenSSL installed but if yours does not you should use the appropriate command to install the package.  On Red Hat based systems use yum:

1
yum install openssl

On Debian based systems use apt-get:

1
apt-get install openssl

STEP: Generate Private Key

It’s best practice to create a new key for each new CSR you sign.  To create a key we first create a working directory:

1
2
mkdir ~/certs
cd ~/certs

Create the key and place in a file:

1
openssl genrsa -out www.contoso.com.key 2048

STEP: Generate CSR

This command will create a Certificate Signing Request (CSR) which we will later use to request the actual certificate:

1
openssl req -new -sha256 -key www.contoso.com.key -out www.contoso.com.csr

You will be prompted to enter some information as shown below, but Microsoft ADCS only cares about the Common Name.   Note that no challenge password should be provided.

1
2
3
4
5
6
7
8
9
10
11
12
Country Name (2 letter code) [XX]:
State or Province Name (full name) []:
Locality Name (eg, city) [Default City]:
Organization Name (eg, company) [Default Company Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:www.contoso.com
Email Address []:
 
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

STEP: Create Certificate

Copy the www.contoso.csr file to a Windows domain joined system such as an issuing CA.

Open cmd prompt and submit the CSR:

1
certreq -submit -attrib "CertificateTemplate:WebServer" -config DOMAINCA\CA1 www.contoso.com.csr www.contoso.com.cer

You must change DOMAINCA\CA1 to be a valid DOMAIN\HOST value for your environment.  You may also need to change “WebServer” to a Microsoft Template name appropriate for your organization.

If all goes right you should see output similar to:

1
2
3
RequestId: 9871
RequestId: "9871"
Certificate retrieved(Issued) Issued

Your certificate should now be in the www.contoso.com.cer file.

Install the certificate and key files:

1
2
3
4
cp www.contoso.com.key /etc/pki/tls/private/
cp www.contoso.com.cer /etc/pki/tls/certs/
chmod 400 /etc/pki/tls/private/www.contos.com.key
chmod 400 /etc/pki/tls/certs/www.contoso.com.cer

STEP: Obtain Trust CA Certificates

You will need to obtain a file containing all your enterprise trusted CAs.  Contact your Microsoft ADCS administrator and ask how to obtain this file.  You need all the certificates in a single PEM file.

Install the CA trust file in:

1
/etc/pki/tls/ca/ca-bundle.crt

STEP: Configure Apache HTTPD

The following steps assume you are on a Red Hat Enterprise Linux 6 or later Linux system.

Edit /etc/httpd/conf.d/ssl.conf and change the following:

1
2
3
SSLCertificateFile /etc/pki/tls/certs/www.contoso.com.cer
SSLCertificateKeyFile /etc/pki/tls/private/www.contos.com.key
SSLCACertificateFile /etc/pki/tls/ca/ca-bundle.crt

Save the file and then restart Apache:

1
systemctl restart httpd

The process is now complete.  All you have to do now is remember to redo this process before your certificate expires.  You could also automate this process using Method – CertAccord Enterprise.

METHOD 2 – CertAccord Automated Certificates

CertAccord Enterprise is a commercial solution which allows enterprises of any size to create certificates on Linux from Microsoft ADCS without manual processes.  Certificates can be created from the Linux command line in a simple command.  Even better certificates are automatically renewed without any manual process.

STEP: Install CertAccord Enterprise

Installation of the CertAccord server can be done in a few hours.  Please refer to CertAccord Enterprise Installation guide for details.

Install the CertAccord Agent on the linux system using the CertAccord Enterprise Installation Guide.  This typically can be one in 1-2 minutes.

STEP: Create Certificate

Open a shell prompt and run;

1
cmb cert create purpose=webserver

You will be prompted for your Active Directory username and password.  After that the certificate will be created and the file names of the certificate, key, and CA trust should be output:

1
2
3
4
5
6
7
Created certificate ID: 7Sp88B4S SUBJECT: "www.contoso.com" SERIAL: 25000001a3dd2d58b4bf2275550000000001a3 PURPOSES: WebServer EXPIRES: "Apr 02 2019 00:57:06 PDT"
Exported Certificate 7Sp88B4S as PEM [CHANGED] FILE: /var/cmb/cert/www.contoso.com-webserver.crt
Exported Private Key [CHANGED] FILE: /var/cmb/cert/www.contoso.com.com-webserver.key
Applying certificate to Apache HTTP Web Server: ID: 7Sp88B4S PURPOSE: WebServer
COMMAND [/bin/systemctl reload-or-restart httpd] ran successfully
Reloaded Apache HTTP Web Server
Apply certificate to Apache HTTP Web Server: ID: 7Sp88B4S RESULT: Succeeded

STEP: Configure Apache HTTPD

The following steps assume you are on a Red Hat Enterprise Linux 6 or later Linux system.

Edit /etc/httpd/conf.d/ssl.conf and change the following:

1
2
3
SSLCertificateFile /var/cmb/cert/www.contoso.com-webserver.crt
SSLCertificateKeyFile /var/cmb/cert/www.contoso.com-webserver.key
SSLCACertificateFile /var/cmb/ca/ca-trust.crt

Save the file and then restart Apache:

1
systemctl restart httpd

The process is now complete.  Sit back and relax without worrying about renewing your certificate.

Summary

Both methods described will get Apache HTTPD configured with TLS.  The OpenSSL method is “free” from licensing cost but is heavy on people time/cost and has no automated renewal process.  It often will lead to service outages because of expired certificates.

The CertAccord Enterprise solution solves the problem and has a very low long term cost because of the time savings both in certificate creation, but also preventing service outages.

Comment • Read More
29 Mar20:19pm

MS-WCCE Automated Solution for Linux

MS-WCCE Automated Solution for Linux

Windows systems have long supported Microsoft Windows Client Certificate Enrollment (MS-WCCE) which provides automatic X.509 certificate deployment and renewal with Microsoft Active Directory Certificate Services (ADCS).  Linux systems have no MS-WCCE support or any other automated integration with ADCS.  This is a key reason we created CertAccord Enterprise.

Much like MS-WCCE on Windows, CertAccord Enterprise on Linux (as well as MacOS X) enables X.509 certificate creation using Microsoft ADCS.  Everything is done automatically with no OpenSSL or web forms or other manual processes.

Create Certificate In One Simple Command

This is all it takes to create a certificate using CertAccord on a Linux system:

1
cmb cert create purpose=webserver

This simple command will send a request to Microsoft ADCS to create an X.509 certificate and then place it on the local filesystem.  No OpenSSL is used.  You don’t have to create a Certificate Signing Request (CSR) and then cut-and-paste it into some web form.

Automatic Certificate Renewals

One of the great features of MS-WCCE is automatic certificate renewals.  How many times have you had manually created certificates on Linux expire and take down a key service?  Once is too many.

Any certificate that CertAccord Enterprise creates will be automatically renewed before it expires.  No more manual processes to track renewals.

Active Directory Authentication

Since MS-WCCE is built into Windows it uses Active Directory (AD) to authenticate certificate requests.  Wouldn’t it be nice if you could do that on Linux?

CertAccord Enterprise integrates with AD.  Whenever you request a certificate creation from Linux CertAccord will prompt for AD username and password.  This credential information will be used to validate the user is allowed to create certificates using CertAccord’s Role Based Access Control (RBAC).  Best of all, the CertAccord AD integration is done purely through CertAccord and does not require the local Linux system be domain joined or have its system level authentication integrated with AD.

Easy Installation

CertAccord Enterprise is designed to quickly and easy install into your existing Microsoft PKI environment.  Typical installs take a few hours.  You don’t have to major any significant changes to your Certificate Authorities or Active Directory configuration.  There is no change to your Linux systems authentication.

Next Steps

Please contact us to see a demo of CertAccord Enterprise and learn how you can bring MS-WCCE features to your Linux and MacOS X systems quickly and easily.

 

Comment • Read More
08 Sep09:41am

Best Practices for Securing Private Keys

Best Practices for Securing Private Keys

When you leave home do you lock the front door but leave the key in the lock?  That’s the same thing as creating a private key but not protecting it. Access to a private key can let an attacker fraudulently sign application content or impersonate a site’s identity.  Common sense would indicate that locking your front door and taking the key with you is a good thing so have you asked yourself if your private keys are secure?

Protecting private keys is vital if you run Linux (Red Hat Enterprise Linux, Ubuntu Linux), Apple MacOS, UNIX (Solaris, AIX, HP-UX), Microsoft Windows, or any other platform.

Introduction

Creating Code Signing Certificates, Server Authentication (Web Server) Certificates, or any other X.509 certificate requires a private key.  The private key is used to sign a Certificate Signing Request (CSR) which is sent to a Certificate Authority which creates the certificate.

The application which uses the certificate requires access to the private key used for the CSR.  Without the private key the application is unable to use the certificate for Code Signing or SSL/TLS (Web Server).

Best Practices for Securing Private Keys

Securing your private keys is not rocket science, but it does take an understanding of best practices and the discipline to build and operate the right processes.

Let’s examine best practices for protecting private keys.

#1 – Hardware Storage

The best way of securely storing private keys is to use a cryptographic hardware storage device such as:

Using such a physical device means that attackers most first gain access to the physical device which can be difficult if the device has restricted access.

If the storage device is portable, such as with USB Token and Smart Cards, then don’t leave the device connected.

HSMs are intended to have a very narrow and protected connection intended for persistent access.  They usually offer the best protection but are often cost prohibitive or impractical.

#2 – Local Filesystem

In some applications it’s impractical to use a Hardware Storage.  One example would be for web servers which are numerous and physical or virtually distributed where the cost of Hardware Storage is prohibitive.  In such a situation the best solution is to generate and store the private key on a local filesystem.

It’s crucial that the generation of the key be done on the same system and the same local filesystem as the storage location.  Generating the key on a server and then transferring the key back to the local system and storing it just adds multiple points of vulnerability.  Why would you want to increase the chance of your private key being compromised?

Well, many products on the market today are based on private keys being generated AND stored on a server.  This means that the keys are vulnerable to snooping when the are transmitted to the client.  The server also becomes a single point of compromise because all the private keys are stored in one place.

Why do these products take this approach? They do this because it’s easier, not because it’s more secure.

CertAccord Enterprise is designed to follow this best practice.  It generates and stores private keys on the local filesystem.  They are never sent over the wire and never stored on another system.

#3 – Limit User Access

Whether you are using hardware or local filesystem to store your private keys, you should restrict access only to the minimal number of users who require access.

For Hardware solutions this typically is controlled by who is issued Hardware devices (USB Token, Smart Card).  Make sure there is a clear and consistent process for issuing, verifying, and collection the devices.

For Local Filesystem storage use filesystem protections such as Access Control Lists (ACLs).  Make sure there is a clear and consistent process for who is granted access and how/when access is removed when a user leaves the project or company.

#4 – Verification Monitoring

Having a process is not always enough protection.  You need to monitor and verify that the process is working.  It’s important that you periodically verify who has access to private keys.  Sometimes people leave projects or the company but their user accounts still have access to private keys.  It’s also possible for an attacker to compromise your process for granting access.  If you have verification monitoring in place, you can catch these types of unexpected events.

Use software to automate the verification monitoring whenever possible.  When that’s not possible, use an independent party to verify or audit current private key access.  This can be done through existing SOX Compliance testing or a new dedicated process.

Summary

The best thing you can do to protect private keys is to use a Hardware Storage solution in combination with the right control processes.  When that is not practical, use Local Filesystem with local key generation in conjunction with the right right control processes.

A product like CertAccord Enterprise, which implements the best practices for Local Filesystem storage, is recommended for generating, storing, and managing private keys.

References

Comment • Read More
02 Aug18:13pm

Linux Certificate Auto Enrollment With Microsoft CA

Linux Certificate Auto Enrollment With Microsoft CA

There is no free Linux “client” which provides Auto Enrollment or integrates with the Microsoft PKI like the one built into Microsoft Windows.   However, there are commercial options which provide very similar abilities, one in particular which is actually easy to install, use, and won’t blowup your budget.

Many commercial and government enterprise organizations leverage Linux for critical services which often require an X.509 trusted certificate.  Typically the need is for an SSL/TLS Server Authentication certificate commonly known as a web server certificate on Red Hat Enterprise Linux (RHEL), Ubuntu Server, or other Linux distribution.

The most common Public Key Infrastructure (PKI) in these same organizations is the Microsoft Enterprise Certificate Authority (CA).   There are no free Linux options which provide automated integration with the Microsoft CA.  This historically leaves organizations the choice of using “free” Linux tools combined with a complex manual process or purchase one of the very large and complex commercial products on the market.

There is a better solution that doesn’t have all the downsides of the “free” solution and doesn’t require substantial budget like the older monolithic commercial solutions.

Free Doesn’t Mean Low Cost

The “free” Linux tools approach typically involves Linux IT admins using the OpenSSL command line to create a private key and certificate signing request (CSR), email the request to the Microsoft PKI Admin, receive back the certificate, and install the certificate and key properly.  Then you also have to have some kind of out-of-band reminder to to repeat this process before the certificate expires.

This might be manageable for a dozen or so systems, but this scales very poorly.

The usual result are certificates with either too long an expiration and/or certificates which expire without being renewed.  Using long, multi-year expiration times is far from ideal because the longer a certificate is valid, the more it is susceptible to weakened cryptography.  Using shorter expiration times shortens the exposure to susceptible cryptography, but comes at the cost of more frequent certificate renewals.

IT admins are human.  They forget things.  One thing they often forget is to renew manually managed certificates.  This leads to service outages and unhappy customers.

Even if your IT admins have the memory of an elephant and the discipline of a Tai Chi Master, the labor costs of creating and managing large numbers of certificates in this manner is huge.

Prepare For Assimilation

There are several behemoth commercial products on the market which can automate the certificate process.  However, these products require “total assimilation” similar to the approach of the fictional The Borg.

You have to integrate each Linux system with Active Directory and switch your user identification authentication over as well.  This requires massive changes to existing Linux and Microsoft infrastructure.

The result is implementation time-frames of 3 months to more than 3 years and have a price tag that starts at $250K for an “entry level” implementation to $1M or more for large organizations.

That’s not easy and it’s not cheap by any means.

The Easy Way

Revocent developed CertAccord Enterprise to solve these problems. CertAccord Enterprise provides a Linux Client for auto enrollment with the Microsoft PKI Certificate Authority.

It is designed to be easy to use by Linux admins who just want to be able to run a simple command to “create web server certificate” and then have the certificate managed (renewed) through-out its life-cycle.   The certificate creator gives the purpose of the certificate without having to know what the company PKI configuration policies are to create a private key or certificate.  That is all configured by the enterprise PKI experts.

The Microsoft PKI administrators use nearly all the same tools and interfaces to manage Certificate Templates (policies) with the addition of the CertAccord Enterprise Console Management web GUI.  The Console is where Linux device registrations are controlled and where certificate Templates (policies) are “connected” to CertAccord for use.

It’s easy to install because it’s designed as a “bolt-on” to your existing Microsoft PKI and Linux infrastructure.  You don’t integrate your Linux systems with AD so it’s a simple installation.

You don’t have to spend a year implementing it and it won’t cost you most of your annual budget.   It’s just easier.

References

 

 

Comment • Read More
28 Jul16:13pm

CertAccord – How To Create Trusted Certificates From Command Line On Linux

CertAccord – How To Create Trusted Certificates From Command Line On Linux

Creating a trusted X.509 certificate on Linux (Red Hat Enterprise Linux (RHEL), Ubuntu Linux, and MacOS X) is fast and simple using CertAccord Enterprise.  Most any IT system administrator can create certificates without having to be a PKI expert.

This article shows you how to create a trusted X.509 certificate from the Linux command line (bash prompt) in just a few minutes.  Once the certificate is created it will be installed locally and managed automatically (including automatic renewals).

Prerequisites

The CertAccord Enterprise Server must be installed and configured to access your enterprise Microsoft Certificate Authority.

STEP 1 – Install CertAccord Enterprise Agent

If you don’t already have the CertAccord Agent installed, you can install it by copying the CertAccord Agent installer to your Linux system.   Then run the installer:

Shell
1
2
chmod +x ./cmbagent-1.0-linux-x64.run
./cmbagent-4.0-linux-x64.run --mode unattended

This command will install the Agent into the default location of /usr/local/cmbagent.

STEP 2 – Register Agent

Shell
1
2
export PATH=/usr/local/cmbagent/bin:$PATH
cmb register server=myserver

Change myserver to be the hostname of the CertAccord Enterprise Server.

When you run this command, the Agent will download the CA trust information from the server, generate a private key locally (configured to adhere to the policies given by the server), and then submit the registration request to the server.

STEP 3 – Create Certificate

To create a web server certificate for use with Apache HTTPD or other web server, run the following command:

Shell
1
cmb cert create purpose=webserver

This command will automatically create a CSR, submit it to the enterprise CA, and install the certificate once issued. This is all done using the PKI policies configured on the CertAccord Enterprise Server and your enterprise CA. No knowledge of these policies or configuration requires are needed by the Linux system administrator when running this command.

Here is example output:

1
2
3
4
5
6
7
8
9
10
Creating Certificate PURPOSES: [WebServer]
Created certificate 634RJ65d [SUBJECT: "dune.contoso.com" PURPOSES: WebServer EXPIRES: Jul 14 2021 13:52:14 PDT]
Saved certificate 634RJ65d [SUBJECT: "dune.contoso.com" PURPOSES: WebServer EXPIRES: Jul 14 2021 13:52:14 PDT] to AgentProfile
Apply Certificate 634RJ65d [SUBJECT: "dune.contoso.com" PURPOSES: WebServer EXPIRES: Jul 14 2021 13:52:14 PDT]
Exported Certificate 634RJ65d [SUBJECT: "dune.contoso.com" PURPOSES: WebServer EXPIRES: Jul 14 2021 13:52:14 PDT] to /var/cmb/cert/dune.magnicomp.com-webserver.crt
Exported PrivateKey Grq8jB3h [RSA 2048] to /var/cmb/cert/dune.contoso.com-webserver.key
Applying certificate to Apache HTTP Web Server: ID: 634RJ65d PURPOSE: WebServer
COMMAND [/usr/sbin/service apache2 reload] ran successfully
Reloaded Apache HTTP Web Server
Apply certificate to Apache HTTP Web Server: ID: 634RJ65d RESULT: Succeeded

The output shows that a certificate was created, saved to the local Agent database, and a copy of the certificate was exported to /var/cmb/cert/dune.contoso.com-webserver.crt. The Apache HTTPD server was also reloaded so that it re-read its configured certificate files.

Summary

A few key take-aways:

  1. Using the CertAccord Agent required no prior knowledge of the enterprise PKI policies for keys or certificates.
  2. Because the certificate was created by the enterprise CA and is not self-signed, the certificate is automatically verifiable by any application in the enterprise.
  3. The Agent manages the life-cycle of the certificate.  That means it will automatically renew the certificate without any human intervention.

References

Comment • Read More