InterSystems IRIS Data Platform 2019.2

First Look: The InterSystems Public Key Infrastructure (PKI)
InterSystems: The power behind what matters   

This First Look introduces you to the InterSystems public key infrastructure (PKI), which can play an important role in your organization’s security strategy. It presents information about public-key cryptography, certificate authorities, and PKI. It then walks through some initial tasks associated with using the InterSystems PKI. Once you’ve completed this guide, you will have created a certificate authority (CA), and then requested and received a certificate from it for a CA client.
This guide uses InterSystems IRIS™ default settings, which allows you to acquaint yourself with the fundamentals of the PKI without having to deal with other details that are important when performing an implementation. For the full documentation on database encryption, see “The InterSystems Public Key Infrastructure” in the InterSystems IRIS Security Administration Guide.
To browse all of the First Looks, including those that can be performed on a free evaluation instance of InterSystems IRIS, see InterSystems First Looks.
Why a PKI Is Important
The frequency of news about security breaches at many organizations makes clear the need to secure their communications. Organizations need to protect data that is traveling from one site to another or when there needs to be some kind of verifiable, legally binding digital signature. Powerful, effective, and pervasive tools to address these and other needs are public-key cryptography and public key infrastructure (PKI).
Public-key cryptography enables the encryption and decryption of data. This provides a means of performing various actions related to securing data. These include protecting data in transit on an unsecured network (such as the Internet) or establishing the provenance of a document. It thereby enables crucial technologies, such as Transport Layer Security (TLS), which is the successor to the Secure Sockets Layer (SSL) and is the means by which browsers protect our connections to web sites.
Public-key cryptography operates on data controlled by distinct entities, where entities can be people, applications, organizations, and so on. However, public-key cryptography alone does not provide sufficient confidence of the identity of these entities in activities, particularly if they do not know each other personally. To achieve that level of confidence, there needs to be a larger structure that also provides trustworthy and verifiable identification information for entities involved. Such a structure is known as a PKI.
A PKI establishes a means for entities to be confident of each other’s identities, even without any direct personal knowledge of or contact with each other. This requires each entity to trust a third party — called a certificate authority (CA) — that vouches for the identity of the other entity (also known as the other peer). With a PKI, entities can perform meaningful and legally binding cryptographic operations, which include encryption, decryption, and digital signing and signature verification.
InterSystems provides a public key infrastructure (PKI) that uses an instance of InterSystems IRIS as a CA, allows you to create key pairs, and allows you to create certificates that are associated with these key pairs. The InterSystems CA is suitable for use within organizations internally and in non-production environments. It is not recommended for use as a production or commercial CA; while its certificates are cryptographically sound, a commercial CA requires a level of organizational and legal infrastructure in additional to technological infrastructure.
Public-key cryptography with a PKI supports a number of vital secure activities:
The Fundamentals of How Public-Key Cryptography and Certificate Authorities (CA) Work Together
When using public-key cryptography, each entity has a private key, which is a closely held secret, and a public key, which is made widely available. If you perform an action with one key, you can perform the complementary action with the other key; for example, if you encrypt data with your private key, then only your public key can decrypt that data. If someone else encrypts content with your public key, only your private key – and therefore, only you – will be able to decrypt it. This means that public-key cryptography provides a means for secure and private communications between two entities.
For public-key cryptography to be useful among entities who do not know each other and who cannot easily verify each other’s identity, there needs to be a third party that both entities trust. This third party is the certificate authority (CA). Certificate authorities create certificates, which are digital documents that bind a public key to a set of identifying information for the public key’s holder. Since the public key and the private key are inextricably tied to each other, a certificate also binds the identifying information to the private key. Some organizations have in-house CAs, which they use to support internal activities; other CAs operate as independent organizations, usually providing certificates as a commercial service. Commercial CAs typically offer certificates based on varying degrees of identity verification; with sufficient verification, a certificate can create a legally binding tie between an organization or person and a public-private key pair. The use of CAs allows entities in an unsecured environment to have sufficient confidence to use public-key cryptography in meaningful and legally binding ways.
Entities that are communicating with each other do not need to use the same CA. Rather, each one simply needs to trust the other’s CA. This relationship of trusting a CA is usually established without any user intervention, such as by having a browser ship with a set of pre-approved CA certificates. In fact, an entity can trust one CA because it has a certificate from a second CA that is already trusted; in this scenario, the first CA is known as an intermediate CA — and there can be multiple intermediate CAs.
When an entity obtains a certificate from a CA, a number of events have occurred – frequently without being visible to the user. First, the CA client uses an algorithm to generate the key pair; the CA client then obtains necessary information to describe the entity using the key pair, which has to do with the entity’s location, organization, and so on. Taken all together, this identifying information comprises a distinguished name (DN). The entity provides the public key and DN information to the CA in the form of a certificate signing request (CSR); it does not provide the private key because, again, this is a closely held secret.
The CA receives the CSR and then processes it according to its procedures. The CA then signs a document that binds the public key to the DN information, thereby creating a certificate (specifically, a certificate that conforms to X.509 standard). Finally, the CA client obtains the certificate from the CA, and then can use it for various activities, such as establishing a TLS connection.
When two entities need to authenticate each other, they use their certificates and the CA’s trusted relationship to them. Hence, when Alice and Bob attempt to communicate via, say, TLS, the TLS handshake performs authentication for each of them as follows:
About the InterSystems PKI
Taken all together, the activities of a CA and of public-key cryptography are part of what is called a public key infrastructure (PKI). Hence, a PKI provides a means of creating and managing key pairs and certificates, and can support cryptographic operations including encryption, decryption, and digital signing and signature verification. InterSystems IRIS includes a PKI.
With the InterSystems PKI, you can set up a Certificate Authority (CA), a CA client, and start sending secured data between users in a matter of steps.
When an instance of InterSystems IRIS is acting as a CA, it is known as a CA server; when an instance is using a CA’s services, it is known as a CA client. A single instance can be both a CA server and a CA client.
When establishing itself as a CA server, an instance of InterSystems IRIS either creates a key pair and then embeds the public key in a self-signed X.509 certificate or it uses a private key and X.509 certificate signed by an outside CA. X.509 is an industry-standard certificate structure that associates a public key with a Distinguished Name (DN).
Trying the InterSystems PKI for Yourself
It’s easy to set up and use the InterSystems PKI. In this example, you will use two instances of InterSystems IRIS. You are going to perform a series of initial operations with instance #1 as a CA (here primarily known as a CA server) and instance #2 as a CA client. The steps are:
The example in this First Look simplifies the process of setting up and using a CA in ways that are not appropriate for a production system. For example, we provide a suggested password that is used to encrypt and decrypt the CA server’s private key. On a production system (or anything other than a demo system such as this one), never use a publicly known password, as this could jeopardize the security of your CA’s private key and therefore your entire PKI; if this key is exposed or compromised, all of a CA’s certificates become untrustworthy.
Similarly, the directory for Certificate Authority’s certificate and private key files is on the same machine as the instance of InterSystems IRIS that you used for this First Look’s exercises. For a production system, this directory should always be on an external device (not a local hard drive or a network server), preferably on an encrypted external device. This is because the directory holds the private key of the CA.
When setting up your production system follow the instructions in the “InterSystems Public Key Infrastructure (PKI)” chapter of the InterSystems IRIS Security Administration Guide.
Before You Begin
To use this procedure, you will need two running instance of InterSystems IRIS. These instances can be on the same or different hosts, but must have network access to each other.
Your choices for InterSystems IRIS include several types of licensed and free evaluation instances; the instance need not be hosted by the system you are working on (although they must have network access to each other). For information on how to deploy each type of instance if you do not already have one to work with, see Deploying InterSystems IRIS in InterSystems IRIS Basics: Connecting an IDE.
Configure Instance #1 as a CA Server
To configure instance #1 as a CA server:
  1. Open the Management Portal for the instance in your browser, using the URL described for your instance in InterSystems IRIS Basics: Connecting an IDE.
  2. Go to the Public Key Infrastructure page (System Administration > Security > Public Key Infrastructure).
  3. On the Public Key Infrastructure page, under Certificate Authority Server, select Configure Local Certificate Authority server. This displays two fields:
  4. Click Next to continue.
  5. In the fields that appear, enter the following values:
    In a production environment, when you configure a CA server, you need to complete the fields in this section to include the email account of the user responsible for signing requests for the CA. For this First Look, you can skip it.
  6. Click Save. InterSystems IRIS displays a message like the following indicating success:
    Certificate Authority server successfully configured. 
    Created new files: C:\InterSystems\MYIRIS1\mgr\flca\FLCA.cer .key, and .srl. 
    Certificate Authority Certificate SHA-1 fingerprint: 
    This indicates that InterSystems IRIS has performed the following actions:
Configure Instance #2 as a CA Client
To configure instance #2 as a CA client:
  1. Open the Management Portal for the instance in your browser, using the URL described for your instance.
  2. Go to the Public Key Infrastructure page (System Administration > Security > Public Key Infrastructure).
  3. Under Certificate Authority Client, select Configure Local Certificate Authority Client, which displays several fields on this page.
  4. Complete the following fields, leaving other fields blank or with their defaults. In the previous section, you used the host identifier and web server port of instance #1, which you must enter here. in its Management Portal URL.
    If this were a CA client in a production system, in the Local technical contact area, you would also complete the Phone number and Email address fields. This would then allow the CA administrator to contact you to verify your identity. This is a mandatory step in a production system, because the CA server should only provide certificates to clients where there is a verifiable identity and the clients need to provide this contact information to begin that process.
  5. Click Save.
InterSystems IRIS acknowledges success through a message such as “Certificate Authority client successfully configured.”
On Instance #2, Submit a Certificate Signing Request (CSR) to the CA Server
Next, on instance #2, submit a certificate signing request (CSR) to the CA server:
  1. Still on the Public Key Infrastructure page (System Administration > Security > Public Key Infrastructure), under Certificate Authority Client, select Submit Certificate Signing Request to Certificate Authority Server, which displays several new fields.
  2. Complete them as follows, leaving other fields blank or with their defaults:
  3. Complete these fields as required and click Save. If successful, InterSystems IRIS then displays a message like the following:
    Certificate Signing Request FLCAclient successfully submitted to the Certificate Authority 
    at instance MYIRIS1 on node FLCATEST.COM. 
    SHA-1 Fingerprint: C2:B0:D6:0D:D6:AB:43:DF:7F:B1:22:AE:14:D7:45:FF:CC:0C:20:D0
    In a production environment, you would need to make a copy of the SHA-1 fingerprint that InterSystems IRIS displays, as you — as the CA client — would need this information as part of the verification process for issuing a certificate.
  4. At this point, you have used InterSystems IRIS to create and submit the CSR.
On Instance #1, Process the CSR
On instance #1 (the CA server), process the CSR, which turns it into a certificate:
  1. In the Management Portal, go to the Public Key Infrastructure page (System Administration > Security > Public Key Infrastructure).
  2. On the Public Key Infrastructure page, under Certificate Authority Server, select Process pending Certificate Signing Requests, which displays the pending CSR from the CA client.
  3. Click Process to the right of the CSR, which displays the contents of the CSR, which displays the fields for processing the CSR. A few important points about these fields:
  4. Click Issue Certificate, which causes the page to display the Password for Certificate Authority's Private Key file field.
  5. In the Password for Certificate Authority's Private Key file field, enter myflcapw, which is the password you created when you configured the CA server.
  6. Click Finish to create the certificate. IRIS displays a message such as
    Certificate number 2 issued for Certificate Signing Request FLCAclient
InterSystems IRIS has now created the certificate. In a production system, it would also have notified the technical contact for the CA client by email that the certificate is available for download.
On Instance #2, Download Its Certificate and CA Server Certificate from the CA Server
The next and final step is for the CA client to download from the CA server both the CA server’s certificate and its own certificate:
  1. In the Management Portal, on instance #2, go to the Public Key Infrastructure page (System Administration > Security > Public Key Infrastructure).
  2. On the Public Key Infrastructure page, under Certificate Authority Client, click Get Certificate(s) from Certificate Authority server.
  3. In the fields that are displayed, there is a Get Certificate Authority Certificate button. Click it, which downloads the CA server certificate and displays a message such as:
    Certificate Authority Certificate 
    (SHA-1 Fingerprint: 8A:38:C9:06:50:A0:4F:71:86:2B:69:4C:A2:42:E0:43:28:C8:70:EB) 
    saved in file "c:\intersystems\MYIRIS2\mgr\FLCA.cer"
  4. Again, click Get Certificate(s) from Certificate Authority server.
  5. The Issued Certificates table lists the CA client’s certificate. Click the Get button next to its row. This downloads the CA client’s certificate and displays a message such as:
    Certificate number 2 
    (SHA-1 Fingerprint: 2E:82:27:73:72:38:BC:71:36:70:DC:9E:0D:EF:E6:BC:0D:A9:95:CD) 
    saved in file "c:\intersystems\MYIRIS2\mgr\FLCAclient.cer"
Wrapping Up and Next Steps
You have now:
This means that you now have one InterSystems IRIS instance that is a functioning CA server and another InterSystems IRIS instance that is a functioning CA client. If you set up a CA client on another InterSystems IRIS instance and create TLS configurations for each instance, the two clients can exchange encrypted messages. This provides the basis for various secured activities.
A final reminder: this example system does not help establish a secure environment because the CA’s private key has been publicly published in this document. It is critical that you properly protect all private keys in production systems, and it is most important that you protect the private key of a CA. The exposure of a private key for use in a production system can result in security breaches, data exposure, financial losses, and legal vulnerability. Do not use this document’s CA server private key for anything other than educating yourself about InterSystems IRIS features.
Learn More About the InterSystems PKI
For full documentation on the InterSystems PKI, see the “InterSystems Public Key Infrastructure” in the InterSystems IRIS Security Administration Guide.

Send us comments on this page
View this article as PDF   |  Download all PDFs
Copyright © 1997-2019 InterSystems Corporation, Cambridge, MA
Content Date/Time: 2019-10-14 06:33:38