Friday, June 5, 2020

Using CertBot to issue certificates with ACME to an Apache Web Server

The popular ACME (RFC8555) agent CertBot can be used to automatically create and renew TLS certificates for an Apache web server. The same setup can easily be used for other web servers that CertBot has support for, for example NGINX. With a TLS certificate, the web server can be reached using the HTTPS protocol, and all traffic to and from the web server is encrypted.

This post describes how to issue private TLS certificates, from your own CA, for usage in your organization.

This picture shows a simplified image approximately what happens in the background when issuing a certificate with ACME.

Prerequisites

Issuing web host certificates using ACME makes use of DNS for authorizing issuance of certificates for a specific domain. Therefore it is important that both the web host and the CA have proper FQDNs and that these are in the DNS. The CA needs to be able to reach the web server, looking up its FQDN in DNS.

The following prerequisites are required to complete the issuance:
  • EJBCA
    • EJBCA Enterprise (with ACME support) deployed on an Ubuntu server, configured with:
      • A CA that will issue web server certificates
      • A certificate profile in EJBCA for the web server certificates
      • An end entity profile in EJBCA for the web server certificates that is configured to use the web server certificate profile
  • Apache web server
    • A server/VM installed with Ubuntu 19.04 (as used in this guide, other operating systems should work the same/similarly)
  • DNS host records
    • A host record for the CA server, used by the web server to contact the CA (in this guide ejbca.example.com)
    • A host record for the web server, used by the CA to contact the web server for ACME http-01 authorization (in this guide tgacme.com and www.tgacme.com

Issue Web Server TLS Certificate over ACME with CertBot

To complete issuance of a web server certificate, follow the steps outlined in the sections below.

Step 1 - Trusted CA Certificate Configuration

In order to contact the CA server over https, the CA certificate that signs your servers (EJBCA and Apache) TLS certificates needs to be installed as trusted in your systems, both the EJBCA host and the Web host. If not, CertBot will not be able to talk to the CA.

In this guide, the Management CA (a Root CA) is used and the Management CA certificate has been downloaded as /tmp/ManagementCA.cacert.pem.

Run the following on both servers:
sudo mkdir /usr/share/ca-certificates/extra/
sudo cp /tmp/ManagementCA.cacert.pem /usr/share/ca-certificates/extra/ManagementCA.cacert.crt
echo 'extra/ManagementCA.cacert.crt' | sudo tee -a /etc/ca-certificates.conf
sudo update-ca-certificates
Next, test that you can access the CA server from both the CA itself and the web server. Example URL: https://ejbca.example.com:8442/

Step 2 - Configure EJBCA on the CA Host

Perform the following steps to configure EJBCA on the CA host:

  1. To configure the Management CA to allow the same subject DN on multiple end entities:
    • In the EJBCA Admin UI, click Certificate Authorities>Management CA>Edit and set the following:
      • Enforce unique public keys = unchecked.
      • Enforce unique DN = unchecked.
  2. To create a Server Certificate Profile, SslServerProfile :
    • To clone the SERVER certificate profile, click Certificate Profiles>SERVER>Clone and set the following:
      • Extended Key Usage = Server Authentication.
      • Available CA: Any CA.
  3. To create a Server End Entity Profile, SslServerProfile:
    • In the EJBCA Admin UI, click End Entity Profiles>Add profile and set the following:
      • End Entity E-mail: Use, Modifiable.
      • Subject DN Attributes: Only CN, Required and Modifiable.
      • Subject Alternative Name: two DNSName.
      • Default/Available Certificate Profile: SslServerProfile.
      • Default/Available CA: Management CA.
  4. Enable the ACME protocol under System Configuration>Protocol Configuration.
  5. Add an ACME alias in EJBCA:
    • In the EJBCA Admin UI, click ACME Configuration>Add and set the following:
      • End Entity Profile: SslServerProfile.
      • Site URL: https://www.primekey.com/
      • Terms of Service URL: https://primekey.com/products/software/
      • DNS Resolver: 8.8.8.8.
  6. Set the ACME alias as Default ACME configuration in the ACME Configuration Overview (EJBCA Admin UI>ACME Configuration).
The following displays an example ACME alias configuration:

Step 3 - Install CertBot on the Apache Web Server Host

On the Web host, install CertBot using the following command. Note that you may need to run sudo apt update on a fresh installation.
sudo apt install python3-certbot-apache
The above command installs the Apache2 web server automatically.

Step 4 - Issue Web Server Certificate

First, to test that https is not available (looks good in a demo), test the following with a web browser:
  • http://tgacme.com - Should show the Apache default web page
  • https://tgacme.com - Should show an error that the browser cannot connect
Next, run certbot to install the certificate from the EJBCA server:
sudo certbot --server https://ejbca.example.com:8442/ejbca/acme/directory -d tgacme.com --apache --agree-tos --email admin@example.com --no-eff-email --noninteractive
Then test with the web browser again:
  • https://tgacme.com - Should now connect and show the Apache default web page.
Additionally, you can go to the certificate view page of your web browser and inspect the web server certificate (that the issuer is the private Management CA).

Step 5 - Configure CertBot for Automatic Monitoring of Expiry

You can now configure CertBot for automatic monitoring of expiry. For information on configuring CertBot, refer to the CertBot documentation.

Additional Notes

Roles and responsibilities

There are at least three distinct roles used in this guide, although they can be more.

  1. CA administrator, performing the configuration of EJBCA. This role can further be divided for CA role separation, for example:
    • CA policy administrator, configuring certificate- and end entity profiles ensuring that properly formatted certificates are issued
    • CA protocol administrator, configuring ACME aliases
  2. Web server administrator, performing configuration of the Apache server and CertBot on the web host.
  3. DNS administrator, adding records to the DNS enabling ACME authorization
In addition it is recommended to monitor all web hosts for expiring certificates. There is a plethora of tools for this, and it's probably included as part of your organization server monitoring solution.

Cleanup/Reset Web Server to Run Again

A simple script can be run on the web host to re-install Apache and CertBot, making it straightforward to run the test as many times as you want, the same fresh installation every time.

The steps are outlined below to describe the process although the script can be run during the initial setup as well.
/home/user/certbot-reinstall.sh
The script does the following:
#!/bin/bash
sudo apt-get -yq remove --purge python3-certbot-apache
sudo apt-get -yq remove --purge apache2
sudo rm -rf /etc/letsencrypt
sudo rm -rf /etc/apache2
sudo apt-get -yq --ignore-missing install python3-certbot-apache
  • Test with browser:
    • http://tgacme.com - Shows the Apache default web page
    • https://tgacme.com - Shows an error that the browser cannot connect.
  • sudo certbot --server https://ejbca.example.com:8442/ejbca/acme/directory -d tgacme.com --apache --agree-tos --email admin@example.com --no-eff-email --noninteractive
  • Test with browser:
    • https://tgacme.com - Connects and shows the Apache default web page.
  • Show the web server certificate in the browser (and verify that it comes from the private Management CA)

CertBot on a Fresh Ubuntu 18.04 or Lower Host

Without updating the Ubuntu repos, the client that will be installed is 0.23. This is older and not supported by EJBCA version > 7.3.0.

To install a newer CertBot version, use the following commands:
sudo apt-get -y update
sudo apt-get -y install software-properties-common
sudo add-apt-repository -y universe
sudo add-apt-repository -y ppa:certbot/certbot
sudo apt-get -y update
sudo apt-get -y install certbot python3-certbot-apache 

Cheers,
Tomas Gustavsson
CTO 

 EJBCA Enterprise PKI and PKI Appliance developed by PrimeKey.

EJBCA is a registered trademark of PrimeKey Solutions AB in the EU, the United States, Japan and certain other countries.

Friday, May 29, 2020

A practical analysis of the SSH Certificate format

I've been messing around a wee bit with SSH certificates, and while the specification is fairly easy to read, reading the actual format was not quite as much so and there was quite a bit of trial and error involved. For the sake of posterity, I thought I'd give a rundown of a sample SSH certificate and how to parse it.

Why use SSH Certificates?
The default use for SSH is with a username/password combo. Why relying purely on username/password is a poor idea is self evident, as passwords are commonly reused/stolen, so the next step up is using SSH keys so that an attacker needs to have also acquired the SSH private key, as well as the password used to protect the key pair. SSH keys can easily be produced using OpenSSH:
$ ssh-keygen -b 384 -t ecdsa -f id_ec384 
The common procedure is then to send your public key off to your favorite IT-admin, who adds it to a list of known keys. If you're an organization of 8000 employees all working from home, your IT-admin is going to be sad and depressed indeed. 

Without going into details in the complete setup (that's a separate blog post, and can be found plenty elsewhere), what your IT-admin can do instead is set up a CA. From there they'll set up some form of RA, and what you instead can do is send in your public key, have it signed and receive a certificate back. This certificate is now your SSH passcode - the difference being that the IT-admin never had to in any way interface directly with your public key. As long as the signature is valid and the certificate hasn't expired, you're good to go.

The Specification
The specification for an RSA certificate is as follows:
78:     string    "ssh-rsa-cert-v01@openssh.com"
79:     string    nonce
80:     mpint     e
81:     mpint     n
82:     uint64    serial
83:     uint32    type
84:     string    key id
85:     string    valid principals
86:     uint64    valid after
87:     uint64    valid before
88:     string    critical options
89:     string    extensions
90:     string    reserved
91:     string    signature key
92:     string    signature
SSH certificates have no similarities to x509, as x509 was by the designers deemed to be overly complex for the purpose. The SSH certificate format also provides some nice perks that x509 does not. So, let's get into it. 

Breaking it down
A sample SSH certificate looks like this.
ssh-rsa-cert-v01@openssh.com AAAAHHNzaC1yc2EtY2VydC12MDFAb3BlbnNzaC5jb20AAAAg5XCeFvniKnNbRZaclB83kTyF8zITCde4uRrv4mqesn4AAAADAQABAAABAQDiFqTBdKOWPeBeP1PiKSVy8ilfNChu5/6Z3iXu3Rdtg5ozu98IoAl4MtlklDdUDzvFkB+VPD/9gqHPKK8fTOhqgUPGoiCeZP3Ktr6NR53xd1QPQDeBvOMiYkPqQXziCQiVyL1WFzN616szrxsJ1Ni7WCHXcMTKOMruLv4es8FfB03wGDbBKVzMwo0JuZCicGg2pg/o8n9BPlzW6CvjUkmvUO3ycGKibPPFkiDgyuYynIbkMcmdShhY3XSOGB4UPeA3U4OiH6Z+09K9LqogWIcjxJeK0tObORd9QnQ4k1ba+/bbEfnFIQwLyzqXXPsPQ0Ud9upxVHD1lezRNE1DAIr9AAAAAAAAAAAAAAABAAAABWVqYmNhAAAAFAAAAAZlamJjYTAAAAAGZWpiY2ExAAAAAF7Q0HgAAAAAYLCytwAAAAAAAACCAAAAFXBlcm1pdC1YMTEtZm9yd2FyZGluZwAAAAAAAAAXcGVybWl0LWFnZW50LWZvcndhcmRpbmcAAAAAAAAAFnBlcm1pdC1wb3J0LWZvcndhcmRpbmcAAAAAAAAACnBlcm1pdC1wdHkAAAAAAAAADnBlcm1pdC11c2VyLXJjAAAAAAAAAAAAAAEXAAAAB3NzaC1yc2EAAAADAQABAAABAQC8ajEtOvKxSPYSRL+A1y7Ye0baYHaR65KkzaT3U5XugHKHusvVPsDlRfSl598TsMjPQhbJt0O1SefMvXCbqdj776PWok5I1ScnLKJWRKzreeslEJZdcKTOUoT9Y5sg/LxC3xXwhIz+yLm8SbvQ7yQvPMmmlg5ldwccC8/0cua/25Vrjm0JhRjgxny65s2bNkClXXLmtevhvlQ7rXMQhpGmg5th156Ny/BUac7CQPEnDkRkhfsH8zKuh0NX19Y/93bwLsI7z+zP7CJJ11C0CpZl5yi2/8vqZUkufjRu/TH78EnLdCE/bkKcn0yyahG5BTh9dInrSclgCSiEPOYojvzjAAABFAAAAAxyc2Etc2hhMi0yNTYAAAEAj4/d9pKGGReo7B1ZbVBtHD9ftBfa5fjyPnuM8qbEMtYWgbx/MlCqVf2CL6VfJe2lvsg4ZZWvHyq0XBucFQqVHMekHJ71CymAs5/boGF4efLo56Ck6FF7tqM4dYmcO0aWRRQt3DyC24bLUZ4ZcdkyAgEm4EbTj9nPyvzbR57VsP/p+6WlszrGAHPwBlZ6my0g3cwPJSxwdV0USfMUIWooMIXLS7ocVZ7a8y+HF6qC2FGYIXYSgJuBaG5jlfXOojfKwA4tzwdy3ZziHxW50WDRkPrw6ZnXeRantJfMOhJ7ol9NSt1WcdkiAHqzDbEUpOz9UF0aSwxtIQYI7ONgl29a7w== Mike's Certificate
We can see right away a nice perk, the certificate begins by telling us what's going to be inside, so off the ball we can figure out how we're going to decode it. The astute of you will notice that the main body of the certificate (between the prefix declaring the type and the comment at the end) looks a lot like Base64, which it very correctly is. If you've seen a certificate or two you'll also notice that every certificate of the same type starts with the same text, and that's because the first characters are (as stated in the specification above) the certificate type, in this case ssh-rsa-cert-v01@openssh.com. So, throw the certificate body into your favorite Base64 decoder and let's move on. 

The byte array follows a simple structure: first a four byte integer declaring the length of the structure, then the contents itself:
What you actually find inside the contents is up to the specification above, hence the importance of knowing beforehand what you're parsing. There can also be additional byte arrays of this format hidden within the payload, as we'll see in a moment. Parsing our way through the byte array, we're going to encounter the following objects, in this exact order:
Item    Description
 nonce   A 16 or 32 bit random byte array generated on the CA, simply to make collision attacks less likely.    
 e  The RSA exponent of the public key for this certificate. Note that EC keys will have the entire key in its own byte structure instead of having its values directly in the certificate. 
 n  The RSA modulus of the public key for this certificate.   
 serial  64 bit unsigned long with a serial number - up to the CA to determine the scheme
 type  32 bit unsigned integer containing a 1 (for user certificates) or a 2 (host certificates) 
 key id  A string filled in by the CA to identify the holder (end entity in x509 terms) owning the certificate.
 valid principals  Our first internal byte structure. The list of principals contains the accounts on the host machine which may be used with this certificate. An empty list will allow any user to make use of this certificate. The structure will look as follows:


 valid after  A 64 bit unsigned long containing the lower bounds of the certificate's validity. 
 valid before  A 64 bit unsigned long containing the upper bounds of the certificate's validity.
 critical options  These will only be relevant for user certificates (as there are no official options for host certificates) and may be force-command (to have the client execute a certain command on authentication to the host) and/or source-address in order to bind the client to a single IP. This is a key-value pair, so adds another layer of complexity to the byte structure


 extensions    The equivalent of x509 key usages, tells SSH what this certificate is authorized to do. There are extensions pre-defined in the specification, but it's up to you if you want to add your own as well. The structure is an array of strings much like principals


 reserved   A blank string, declared but not used at the moment.
 signature key  This is where it starts getting fun. OpenSSH allows the signature key to be of any OpenSSH usable format regardless of the key being signed, so there is for example no reason why a RSA CA can't sign a set of EC keys. The signature key is going to be parsed as a byte structure and then parsed up into its component. The structure of the key is defined in RFC 4253, and for an RSA key would be as follows:
 string "ssh-rsa"
mpint e
mpint n
The nice part is that the first thing the key does is declare itself, so you know exactly how to parse the rest of the structure. 


 signature   Last but not least, the last byte array you're going to read is the signature. This is going to be again an embedded byte structure, starting with a string declaring the signature algorithm, and after that the actual signature, the data for which is all of the preceding fields including the signing key. 


And that's pretty much it! Happy hacking, and I hope I've managed to make somebody's day a bit better.

Cheers,
Mike Agrenius Kushner
Product Owner, EJBCA

Wednesday, April 22, 2020

CVEs: PrimeKey takes a step forward

A question we've been posed through the last few years is whether PrimeKey writes CVEs for known security issues. We're now implementing a change in this policy, and we'd like to talk a bit about it.

Our policy until now has been to fix minor issues with announcements in the release notes, while major vulnerabilities have been immediately patched and customers have been informed about the issue, its severity and possible workarounds.

As PrimeKey has grown as a company and our product line has come to become one of the most commonly used solutions for PKI - in the internal corporate sphere, in distributed production models for IoT devices and not to mention the world of Web PKI - we've chosen to take a step forward and start submitting CVEs for all new and found exposures and vulnerabilities in EJBCA.

What is a CVE? 

CVE stands for Common Vulnerabilities and Exposures, and is a general format for describing an security issue. The original driving force for defining the format was the lack of commonality between the differing sets of vulnerability databases existent at the time. The point of CVE is not to replace these databases but to create a common catalogue of issues linking these together. In a CVE context
  • vulnerabilities are defined as issues where logic errors allow the application to be used in ways other than it was intended. 
  • exposures are configuration issues or bugs that causes the application to leak sensitive information. 
The pertinent parts of a CVE are:
  • The CVE ID
  • A brief description of the issue
  • Links to the vendor's support portal or other source of security advisories
Fix information, impact and other data about the vulnerability are not included in the CVE, but expected to be on the vendor's support portal, i.e PrimeKey's support portal in this case. 

A CVE is created by a CVE Numbering Authority (CNA), which analyses reports and writes CVEs. A report can be submitted by anybody (not just the software vendor), and the CNA does its best to avoid duplicate reports. Many large vendors become CNAs in their own right, but the main CNA is the US government funded MITRE Corporation, which is the entity which would handle reports about PrimeKey products. 

Once a CNA has written a CVE and assigned it a number it's submitted to the NIST National Vulnerability Database and assigned a score based on the severity. 

PrimeKey and CVEs

Starting from Q1 2020, PrimeKey has decided to start submitting all found vulnerabilities and exposures in EJBCA. Our internal policy is that once an issue which is classed as either is found, it is to be patched onto the latest stable releases and made available to customers, along with announcements on our support portal and and security announcements on our mailing lists.

Two working weeks after the customer release we will submit the CVEs, hence making the found security issues public. This period is meant to give customers, if affected by the issue, a chance to upgrade to the latest patch before the issues become public knowledge. For any issues that we deem to be major we will also follow up with a release of EJBCA Community. 

Classification

In order to be completely transparent, PrimeKey has internally classified security issues as the following types:

Vulnerability

A logic error, bug or missing security check (such as XSS or CSRF) in one of our applications with a clear path of being able to make the application perform an action to which it was not intended, or otherwise allow a user to perform an action of which they are not intended to perform. A vulnerability does not need to end up with the application in a compromised state as multiple seemingly benign vulnerabilities can be linked together into a chain ending up in a successful compromise.
Result: A CVE will be submitted

Security Hardening 

Similar to a vulnerability, but without any known exploit vector. Hardenings are performed preemptively in order to avoid vulnerabilities from forming in future code iterations. Examples of what we classify as hardings are adding or improving security headers of web apps (such as CSP headers) or redundant integrity checks on transmitted data. 
Result: A CVE will not be submitted

Exposure

As described above, a common misconfiguration that allows a user to see sensitive data of which they're not privy. This does not include data such as stack traces or internal IDs, as they relay nothing which is either not public or already publicly known through the source code. 
Result: A CVE will be submitted

Vulnerability in an underlying library

As our products make use of various 3rd party libraries, vulnerabilities may in time be reported in them (along with their respective CVEs). If we find that any of these vulnerabilities cause similar issues in existing versions of our products, we will submit our own CVE along with releasing patches.
Result: A CVE will be submitted

Our First CVEs

Thanks to Matthias Kaiser of Apple Information Security, who performed some very diligent penetration testing, we have submitted the following CVEs for EJBCA:
Mike Agrenius Kushner
Product Owner EJBCA

Tuesday, February 18, 2020

Enroll Using Device Certificates through CMP with 3GPP/LTE


About 3GPP/LTE

The 3rd Generation Partnership Project, 3GPP, has produced a technical specification for an entity authentication framework, which was developed in the context of the Network Domain Security work item.

In practice, the main purpose of using CMP 3GPP is to allow a device to automatically provision itself with a device certificate without the vendor being required to expose their full PKI to the manufacturer. A typical use case is an IOT device vendor, whose devices are manufactured by a second party, and the vendor requires the devices to be enrolled to their PKI. The vendor may wish to prohibit the manufacturer from producing their own pirated devices that connect to the vendor's PKI, or is simply unwilling to expose their PKI directly to the manufacturer in order to enroll the devices on site.

 To solve this, the following workflow is usually followed:


  1. The factory site is provisioned with a Vendor CA, separate from the main PKI intended to be used. The Vendor CA certificate is signed by the vendor's PKI. 
  2. The vendor prepares a series of unique identifiers (i.e serial numbers) for each device to be produced. This ensures that only the authorized set of devices will be able to enroll against the vendor's PKI. 
  3. As each device is manufactured it produces its own key pair. The public key is signed by the Vendor CA, and the device is initially provisioned with a Vendor Certificate (which includes the serial number). 
  4. As each device comes online it enrolls to the vendor's PKI over CMP with 3GPP, using the Vendor Certificate to authenticate itself. 
  5. The device then receives its device certificate from the vendor's PKI. 

Generalized Workflow

This section describes the general CMP 3GPP workflow, purely for overview purposes. The EJBCA specific workflow is slightly modified, see the next section. Next figure shows the general deployment architecture for certificate enrollment of a device at an operator PKI:


The device is either pre-provisioned with a public-private key pair by the vendor or produces its own, and has the vendor-signed certificate of its public key pre-installed.

On initial contact to the operator network, the device establishes a communication channel to the RA/CA of the vendor. Using a CMPv2, a request for a certificate is sent to the RA/CA. The network authenticates the messages from the device based on the vendor-signed certificate of the device and the vendor root certificate pre- installed in the network. The device checks the integrity protection on the messages from the RA/CA based on the operator root certificate provisioned in the device. In a response message, the device receives the operator-signed certificate. During the execution of the CMPv2 protocol, the device has to provide a successful proof of possession of the private key associated to the public key in order to be certified.

The operator root certificate may be provisioned in the device prior to or during the CMPv2 protocol run. The protection of the operator root certificate during provisioning may be decided by operator security policy. If an operator root certificate provisioned prior to the CMPv2 protocol run is available, the device shall use it. Otherwise, the device shall use the operator root certificate provisioned during the CMPv2 run. If no operator root certificate is provisioned at all, then the device shall abort the procedure.

If the operator wants to renew the device certificate, the same procedure will be executed with the old operator-signed device certificate taking the place of the vendor-signed certificate of the initial enrollment.

The figure below describes the general message flow in both cases:

  1. The device discovers the RA/CA address.
  2. The device generates the private/public key pair to be enrolled in the operator CA, if this is not pre-provisioned.
  3. The device generates the Initialization Request (IR). The CertReqMsg inside the request specifies the requested certificate. If the suggested identity is known to the device, it includes this in the subject field. To provide proof of possession, the device generates the signature for the POPOSigningKey field of the CertReqMsg using the private key related to the public key to be certified by the RA/CA. The device signs the request using the vendor provided public key, and includes the digital signature in the PKIMessage. Its own vendor signed certificate and any intermediate certificates are included in the extraCerts field of the PKIMessage carrying the initialization request.
  4. The device sends the signed initialization request message to the RA/CA.
  5. The RA/CA verifies the digital signature on the initialization request message against the vendor root certificate using the certificate(s) sent by the device. The RA/CA also verifies the proof of the possession of the private key for the requested certificate.
  6. The RA/CA generates the certificate for the device. If the suggested identity of the device is not included in the initialization request message, the RA/CA determines the suggested identity, based on the vendor provided identity contained in the device certificate. The RA/CA may also replace a suggested identity sent by the device with another identity based on local information.
  7. The RA/CA generates an Initialization Response (IP) which includes the issued certificate. The RA/CA signs the response with the RA/CA private key (or the private key for signing CMP messages, if separate), and includes the signature, the RA/CA certificate(s) and the operator root certificate in the PKIMessage. The appropriate certificate chains for authenticating the RA/CA certificate(s) are included in the PKIMessage.
  8. The RA/CA sends the signed initialization response to the device.
  9. If the operator root certificate is not pre-provisioned to the device, the device extracts the operator root certificate from the PKIMessage. The device authenticates the PKIMessage using the RA/CA certificate and installs the device certificate on success.
  10. The device creates and signs the CertificateConfirm (certconf) message.
  11. The device sends the PKIMessage that includes the signed CertificateConfirm to the RA/CA.
  12. The RA/CA authenticates the PKI Message that includes the CertificateConfirm.
  13. The RA/CA creates and signs a Confirmation message (pkiconf).
  14. The RA/CA sends the signed PKIMessage including the pkiconf message to the device.
  15. The device authenticates the pkiconf message

EJBCA Specific Workflow

To use EJBCA with 3GPP, the setup above should be slightly adjusted:

Direct CA - Device Communication

In the case of direct contact between EJBCA and the device, EJBCA operates in client mode. Each device has a corresponding end entity in EJBCA. The initial enrollment request/certification request is send by the device to EJBCA as a CMP request signed by the key provided to the device by the vendor. The vendor issued certificate is attached to the request in the extraCerts field. EJBCA will authenticate the request by checking that the certificate in extraCerts was issued by the vendor CA (an external CA in EJBCA). If the authentication succeeds, EJBCA will issue a certificate for the device and includes it in the CMP response message.

For future communication, when the device needs to update its certificate, the old EJBCA obtained certificate is used to authenticate the update or key renewal request. This is typically done by the device signing the update request with its private key and attaching its certificate (the one to be renewed) in the extraCerts field in the CMP message.

CA - Device Communication Through a Bespoke RA

In case of indirect communication between EJBCA and the device, EJBCA operates in RA mode. The device communicates with the CA through a third device/organization that acts as an RA. The RA has a corresponding end entity in EJBCA with an issued certificate. This certificate is transported to the RA manually. The RA is also registered in EJBCA as an administrator and is given the necessary privileges to process CMP requests on behalf of the device.

Both initialization/certification requests and certificate update requests regarding the devices, are expected to be signed by the RA. Any changes or updates of the RA certificate are expected to be performed directly in EJBCA and transported to the RA manually.

Cheers,
Mike Agrenius Kushner
Product Owner, EJBCA

Wednesday, October 9, 2019

PGP Signing with SignServer


This blog post covers PGP signing support implemented in recent versions of SignServer

In a previous blog post, we addressed Code Signing of Windows binaries (Authenticode) and gave some background on why Code Signing is important for secure software distribution.

We are now pleased to introduce code signing with PGP, commonly used for Open Source software projects and packaging of software for Linux environments in general.

OpenPGP Signing was first implemented in SignServer Enterprise 5.1 and will be available in SignServer Community 5.2, already available for download as a beta release.

SignServer Installation

To test the PGP support, download and install SignServer Enterprise 5.1 or SignServer Community 5.2.0.Beta1 or later.

For installation instructions, refer to SignServer Installation.

Setting up an OpenPGP Signer

When SignServer is up and running, access the SignServer Administration Web to start setting up the workers.

The Administration Web is available in SignServer Community as if 5.2.0.Beta1.

Step 1: Set up Crypto Worker

If you don’t already have a crypto worker configured, then set one up using, for example, the sample keystore:
  1. Select the AdminWeb Workers tab, and click Add.
  2. Click From Template, select keystore-crypto.properties in the list, and click Next.
  3. In the configuration text view, change the value for WORKERGENID1.KEYSTOREPATH so that the path corresponds to your SignServer installation, for example: WORKERGENID1.KEYSTOREPATH=/home/username/signserver/res/test/dss10/dss10_keystore.p12. 
  4. Click Apply.
Remember the name of the crypto worker (for example, CryptoTokenP12) as you will need it in the next step when setting up the OpenPGP Signer.

Step 2: Set up OpenPGP Signer

To set up the new OpenPGP signer, do the following:
  1.  Select the SignServer AdminWeb Workers tab, and click Add to add a new worker.
  2. Choose the method From Template.
  3. Select openpgpsigner.properties in the Load from Template list and click Next.
  4. Change the sample configuration properties as needed, for example:
    • Update the CRYPTOTOKEN property with the name of your crypto worker (for example, CryptoTokenP12).
    • Update DEFAULTKEY to an existing key (or do this in a later step).
  1. Click Apply to load the configuration and list the worker in the All Workers list.
  2. Select the added worker in the list to open the Worker page.
  3. Check if the Worker status is Offline and if there are any errors listed. The "No key available for purpose" message means that the DEFAULTKEY property does not point to an existing key in the crypto token. In that case, either update the DEFAULTKEY property to point to an existing key or do the following to generate a new key to use with this signer:
    • Click Renew key and specify the following:
      • Set a Key Algorithm, for example "RSA".
      • Set a Key Specification, for example the key length "2048" (for RSA).
      • Update the New Key Alias to the name of DEFAULTKEY property (typically change to the same value as the Old Key Alias).
    • Click Generate.
    • Select the worker in the list and confirm that the Worker status is Active and without errors listed. If not, confirm that the DEFAULTKEY property is correct and check in the Crypto Token tab of the crypto worker that a key with the specified name exists.

Step 3: Add User ID to Public Key

Follow the steps below to add User ID / Certification for the OpenPGP public key using the Generate CSR option.
  1. Select the AdminWeb Workers tab.
  2. Select the OpenPGP worker and click Generate CSR.
  3. Specify a Signature Algorithm, for example "SHA256withRSA"
  4. Specify DN as the wanted User Id, for example "Markus (Code Signing) <markus@primekey.se>".
  5. Click Generate, and then click Download.
  6. Open the downloaded file using any text editor and copy its content.
  7. Select the worker and click the Configuration tab.
  8. For the PGPPUBLICKEY property, click Edit.
  9. Paste the public key content in the Value field, and click Submit.
  10. Click Status Summary and confirm that fields like PGP Key ID and PGP Public key are listed. Also, note that the User ID is listed. 

Step 4: Sign

The following example shows how to sign using the SignServer Public Web. You can test signing using any of the SignServer client interfaces.
  1. Click Client Web.
  2. Under File Upload, specify the Worker name used, for example, OpenPGPSigner.
  3. Select the file to create a detached signature for, for example, release.zip.
  4. Click Submit and store the resulting signature file, for example, release.zip.asc.

Step 5: Verify Signature

The following example shows how to verify the signature using the OpenPGP tool GnuPG. It should be possible to use any OpenPGP tool to verify the signature.

Run the following to verify the signature using GnuPG:
$ gpg --verify release.zip.asc release.zip

If needed, first import the public key to GnuPG before verifying the signature in the third step:
  1. Store the public key (i.e. from PGPPUBLICKEY property) as signer001-pub.asc.
  2. Import the key to GnuPG:
    $ gpg --import signer001-pub.asc

More Information

See also the OpenPGP Signer documentation and if you have any questions or comments don't hesitate to use our discussion forums.

Cheers,
the PrimeKey SignServer Team