• Public Key Example
• Generate Private Key From Public Key In Common Core
• Generate Private Key From Public Key In Common Practice

First, create the key pair: sn -k keypair.snk Next, extract the public key from the key pair and copy it to a separate file: sn -p keypair.snk public.snk Once you create the key pair, you must put the file where the strong name signing tools can find it.

Generate a keypair and CSR using the gencert script and, using the InCommon Certificate Service, provision and install an InCommon SSL certificate for an Apache HTTP Server (httpd) on RHEL 6 Beginning on Feb. 1, 2011, a new Intermediate CA is used to sign InCommon-issued certificates. Feb 26, 2018 This article will explain at a high-level Private and Public Key Cryptography used in Bitcoin and it’s unique security feature. We will be looking at how Public Keys are generated, why this is.

Creating and managing keys is an important part of the cryptographic process. Symmetric algorithms require the creation of a key and an initialization vector (IV). The key must be kept secret from anyone who should not decrypt your data. The IV does not have to be secret, but should be changed for each session. Asymmetric algorithms require the creation of a public key and a private key. The public key can be made public to anyone, while the private key must known only by the party who will decrypt the data encrypted with the public key. This section describes how to generate and manage keys for both symmetric and asymmetric algorithms.

Symmetric Keys

The symmetric encryption classes supplied by the .NET Framework require a key and a new initialization vector (IV) to encrypt and decrypt data. Whenever you create a new instance of one of the managed symmetric cryptographic classes using the parameterless constructor, a new key and IV are automatically created. Anyone that you allow to decrypt your data must possess the same key and IV and use the same algorithm. Generally, a new key and IV should be created for every session, and neither the key nor IV should be stored for use in a later session.

To communicate a symmetric key and IV to a remote party, you would usually encrypt the symmetric key by using asymmetric encryption. Sending the key across an insecure network without encrypting it is unsafe, because anyone who intercepts the key and IV can then decrypt your data. For more information about exchanging data by using encryption, see Creating a Cryptographic Scheme.

The following example shows the creation of a new instance of the TripleDESCryptoServiceProvider class that implements the TripleDES algorithm.

When the previous code is executed, a new key and IV are generated and placed in the Key and IV properties, respectively.

Sometimes you might need to generate multiple keys. In this situation, you can create a new instance of a class that implements a symmetric algorithm and then create a new key and IV by calling the GenerateKey and GenerateIV methods. The following code example illustrates how to create new keys and IVs after a new instance of the symmetric cryptographic class has been made.

When the previous code is executed, a key and IV are generated when the new instance of TripleDESCryptoServiceProvider is made. Another key and IV are created when the GenerateKey and GenerateIV methods are called.

Asymmetric Keys

The .NET Framework provides the RSACryptoServiceProvider and DSACryptoServiceProvider classes for asymmetric encryption. These classes create a public/private key pair when you use the parameterless constructor to create a new instance. Asymmetric keys can be either stored for use in multiple sessions or generated for one session only. While the public key can be made generally available, the private key should be closely guarded.

A public/private key pair is generated whenever a new instance of an asymmetric algorithm class is created. After a new instance of the class is created, the key information can be extracted using one of two methods:

• The ToXmlString method, which returns an XML representation of the key information.

• The ExportParameters method, which returns an RSAParameters structure that holds the key information.

Both methods accept a Boolean value that indicates whether to return only the public key information or to return both the public-key and the private-key information. An RSACryptoServiceProvider class can be initialized to the value of an RSAParameters structure by using the ImportParameters method.

Asymmetric private keys should never be stored verbatim or in plain text on the local computer. If you need to store a private key, you should use a key container. For more on how to store a private key in a key container, see How to: Store Asymmetric Keys in a Key Container.

The following code example creates a new instance of the RSACryptoServiceProvider class, creating a public/private key pair, and saves the public key information to an RSAParameters structure.

See also

Generate a keypair and CSR using the gencert script and, using the InCommon Certificate Service, provision and install an InCommon SSL certificate for an Apache HTTP Server (httpd) on RHEL 6

Beginning on Feb. 1, 2011, a new Intermediate CA is used to sign InCommon-issued certificates. In the text that follows, substitute this new certificate,CN=InCommon Server CA, for the CN=COMODO High-Assurance Secure Server CA certificate mentioned.

More recently, SHA-2 certificates from Comodo use yet another set of intermediate certificates. The examples that follow again are generically correct, but the details on the names and numbers of the intermediate CA's will differ with these new SHA-2 certs.

To begin, let's generate a private key, a certificate signing request (CSR) for the public key, and a self-signed certificate (generated but not used in our case) for the host test.training.berkeley.edu:

sudo gencert test.training.berkeley.edu
Generating RSA private key, 2048 bit long modulus ..
[CSR is displayed to standard output and stored as described below]

At this point, the Comodo-signed InCommon certificate can be provisioned using the InCommon CA Certificate Manager application with the generated CSR file content (or with the copied-and-pasted standard output text from the gencert script). In the e-mail that you then receive from cert-manager.com (or by using the View control button for an approved certificate entry within the Certificate Manager application) you'll see various links for downloading your certificate. Download and store the certificate files according to the following table:

Note that the second file (test_training_berkeley_edu.cer) is a certificate bundle file (a concatenated set of certificates stored in a single file) containing three certificates in base64 format. We will use a subset of that text file to create a new certificate bundle file for Apache with the Root and Intermediate CA certificates reordered into the standard RFC 5246 preferred order (see below).

To examine the individual certificates provided (and to simplify the later creation of a new Root/Intermediate bundle file), open as a source file the test_training_berkeley_edu.cer certificate bundle file using your favorite text editor. Now save the text components corresponding to each certificate into three new files named cert1.cer (topmost certificate in the source file), cert2.cer (middle certificate in the source file), and cert3.cer (bottom certificate in the source file).

To verify the identities of the various certificate files, use a certificate manager such as found with the common web browsers to import and view the certificates, or use the openssl utility to examine the Subject and Issuer fields of each individual certificate:

We can conclude that cert1.cer corresponds to the self-signed Root CA certificate in this chain, cert2.cer corresponds to the Intermediate CA certificate signed by the Root CA, and cert3.cer corresponds to the server certificate signed by the Intermediate CA that was issued by the InCommon CA in response to the submitted CSR.

Combining Subject and Issuer information into a single table shows the complete chain of trust in certificate validation order, starting with the server certificate, then the Intermediate CA, and ending with the self-signed Root CA:

All three of these certificates (the Root CA and Intermediate CA two certificates to be bundled within a single file) are made available to the Apache HTTP Server along with the private key file generated initially. This will allow the Server to assert the entire certificate trust chain to an SSL/TLS client application such as a web browser.

Comparing these three certificates to the second downloaded file shows that it contains only a single component of the certificate trust chain: the X509 Certificate only file (saved as test_training_berkeley_edu_cert.cer) contains the server certificate alone, and is identical in content to the cert3.cer file generated above.

Further, if you were to download the file labeled X509 Intermediates/root only, you would find that it contains the root CA certificate plus the intermediate CA certificate in that order in a certificate bundle file. However, since the standard RFC 5246 preferred order is different, we create our own certificate bundle file instead (see below).

Note that the bundle files as provided by the InCommon CA has recently changed to include the intermediate and root CA certificates in two sequences to fit more environments: X509 Intermediates/root only, Base64 encoded and X509 Intermediates/root only Reverse, Base64 encoded. Note also that the TLS standard (see the quotation at the end of the page below) permits omitting the self-signed Root CA certificate from the asserted chain of certificates. Thus, another deployment option is to install as the Apache Certificate Chain File just the Intermediate CA certificate file (cert2.cer) rather than the certificate bundle file consisting of both the Intermediate and Root CA certificates (the contents of cert2.cer plus cert1.cer combined in that order into a single file) as recommended by the Comodo KB articles cited in this document.

Install for Apache HTTP Server with mod_ssl

There are two certificate files that the Apache HTTP Server configuration file for SSL will reference in addition to the server's own private key file (SSL Certificate Key File):

1. an SSL Certificate File containing the signed certificate bearing the server's public key
2. an SSL Certificate Chain File containing the bundle of certificates bearing the public keys for the Intermediate and Root CAs.

In the previous section we identified the individual certificate files as:

To create an SSL Certificate Chain File (a certificate bundle file) in the standard RFC 5246 preferred order for use with Apache HTTP Server, copy cert2.cer and cert1.cer into a new file, CA-bundle.cer, in that order, and copy the newly created bundle file to the standard installation location:

cat cert2.cer cert1.cer > CA-bundle.cer sudo cp CA-bundle.cer /etc/pki/tls/certs

We now have the three files in place that Apache HTTP Server 2.x needs to implement SSL on RHEL 6. In the syntax of the Apache configuration file, these are defined as in the following excerpt, including first a directive to enable the SSL support engine. These statements typically occur within a <VirtualHost> section:

Note that private key files (test.training.berkeley.edu.key in our example) contain sensitive information which content should only be readable by the account starting the Apache HTTP Server, typically the root account on RHEL 6. If not already set for your private key files, use chmod to set restrictive permissions, for example:

sudo chmod 0400 /etc/pki/tls/private/*

Refer to the Comodo KB article Certificate Installation: Apache & mod_ssl for additional details on the Apache configuration steps.

Public Key Example

For advanced reading on the general topic of the Transport Layer Security (TLS) protocol, the current generation of SSL technology for the Internet, refer to the TLS RFC, where one can find such things as the certificate chaining order definition:

Generate Private Key From Public Key In Common Core

certificate_list

Generate Private Key From Public Key In Common Practice

This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case.