+1-408-638-9323 info@revocent.com

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:

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:

STEP 3 – Generate CSR

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

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

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:

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

STEP 2 – Register Agent

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:

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:

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

 

Read More

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:

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

STEP 2 – Register Agent

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:

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:

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

Read More

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:

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.

 

Read More

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:

On Debian based systems use apt-get:

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:

Create the key and place in a file:

STEP: Generate CSR

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

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.

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:

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:

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

Install the certificate and key files:

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:

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:

Save the file and then restart Apache:

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;

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:

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:

Save the file and then restart Apache:

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.

Read More

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:

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.

 

Read More

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

Read More

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:

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

STEP 2 – Register Agent

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:

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:

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

Read More

How To Create Trusted X.509 Certificates On Linux

How To Create Trusted X.509 Certificates On Linux

Creating trusted enterprise certificates on Linux 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 Linux and the easy CertAccord process.

Traditional Certificate Creation

The traditional process of creating a trusted certificate on Linux is based on using the OpenSSL command line tool available with nearly all Linux distributions such as Red Hat Enterprise Linux, CentOS Linux, Ubuntu Linux, Debian Linux, SuSe Linux, and many others.

STEP 1 – Install OpenSSL

To get started you need to see if you already have OpenSSL installed.  Open a shell and run:

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”.

To install OpenSSL on Red Hat based Linux which using yum, run the command:

To install OpenSSL on Ubuntu and other Debian based Linux using apt-get, run:

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:

STEP 3 – Generate CSR

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

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

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 Linux 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 Linux / 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 Linux system.   Then run the installer:

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

STEP 2 – Register Agent

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:

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:

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 Linux.  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

 

Read More