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

Blog

  • 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: [crayon-5df14923bdb0b095128973/] 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: [crayon-5df14923bdb1e814763849/] STEP 3 – Generate CSR Now we will create the Certificate Signing Request (CSR): [crayon-5df14923bdb23481773497/] This command will save the CSR to the my.csr file. You will be prompted to fill-in various fields: [crayon-5df14923bdb27992552370/] 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: [crayon-5df14923bdb2e417047251/] This command will install the Agent into the default location of /Applications/CertAccord. STEP 2 – Register Agent [crayon-5df14923bdb34715721449/] 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: [crayon-5df14923bdb39850694155/] 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: [crayon-5df14923bdb3d828589772/] 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: Using the CertAccord Agent required no prior knowledge of the enterprise PKI policies for keys or certificates. 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. 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 CertAccord Enterprise OpenSSL Home Page  

  • 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: [crayon-5df14923be3c9922976626/] This command will install the Agent into the default location of /Applications/CertAccord. STEP 2 – Register Agent [crayon-5df14923be3d3324004848/] 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: [crayon-5df14923be3d8446749239/] 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: [crayon-5df14923be3dc712574317/] 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: Using the CertAccord Agent required no prior knowledge of the enterprise PKI policies for keys or certificates. 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. The Agent manages the life-cycle of the certificate.  That means it will automatically renew the certificate without any human intervention. References How to Create Trusted Certificates from Command Line on Linux CertAccord Enterprise

  • 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: [crayon-5df14923be70c243946184/] 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.  

  • 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 CertAccord Enterprise Revocent company website: www.revocent.com Apple MacOS X  

  • 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: [crayon-5df14923be9bf568198445/] On Debian based systems use apt-get: [crayon-5df14923be9c6347907407/] 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: [crayon-5df14923be9ca707186508/] Create the key and place in a file: [crayon-5df14923be9ce314179848/] STEP: Generate CSR This command will create a Certificate Signing Request (CSR) which we will later use to request the actual certificate: [crayon-5df14923be9d2182593224/] 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. [crayon-5df14923be9d5210994824/] 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: [crayon-5df14923be9da288781839/] 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: [crayon-5df14923be9de537007198/] Your certificate should now be in the www.contoso.com.cer file. Install the certificate and key files: [crayon-5df14923be9e2395409460/] 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: [crayon-5df14923be9e6452778460/] 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: [crayon-5df14923be9ec437788594/] Save the file and then restart Apache: [crayon-5df14923be9f0924552947/] 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; [crayon-5df14923be9f4443928337/] 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: [crayon-5df14923be9f8731193138/] 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: [crayon-5df14923be9fd425918253/] Save the file and then restart Apache: [crayon-5df14923bea01554226603/] 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.

  • 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: [crayon-5df14923beed4704230471/] 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.  

  • 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: USB Token Smart Card Hardware Storage Module (HSM) 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 CertAccord Enterprise

  • 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 CertAccord Enterprise Revocent company website: www.revocent.com Red Hat Enterprise Linux (RHEL) Ubuntu Server    

  • 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: [crayon-5df14923bf150386984457/] This command will install the Agent into the default location of /usr/local/cmbagent. STEP 2 – Register Agent [crayon-5df14923bf157041639490/] 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: [crayon-5df14923bf15c842529688/] 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: [crayon-5df14923bf160486161462/] 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: Using the CertAccord Agent required no prior knowledge of the enterprise PKI policies for keys or certificates. 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. The Agent manages the life-cycle of the certificate.  That means it will automatically renew the certificate without any human intervention. References How to Create Trusted Certificates from Command Line on Mac OS X CertAccord Enterprise Red Hat Enterprise Linux (RHEL) Ubuntu Linux

  • 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: [crayon-5df14923bf528618853285/] 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: [crayon-5df14923bf52f255778549/] To install OpenSSL on Ubuntu and other Debian based Linux using apt-get, run: [crayon-5df14923bf533941266177/] 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: [crayon-5df14923bf538697142518/] STEP 3 – Generate CSR Now we will create the Certificate Signing Request (CSR): [crayon-5df14923bf53b426882435/] This command will save the CSR to the my.csr file. You will be prompted to fill-in various fields: [crayon-5df14923bf53f380167185/] 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: [crayon-5df14923bf546440258928/] This command will install the Agent into the default location of /usr/local/cmbagent. STEP 2 – Register Agent [crayon-5df14923bf54b321765862/] 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: [crayon-5df14923bf550706104988/] 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: [crayon-5df14923bf554497295948/] 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: Using the CertAccord Agent required no prior knowledge of the enterprise PKI policies for keys or certificates. 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. 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 CertAccord Enterprise OpenSSL Home Page