Generate Key Pair
Prev Chapter 5. CERTivity®'s KeyStore Next

Generate Key Pair

In order to generate a Key Pair and add it into the current KeyStore, click on Generate Key Pair. A new window will be opened, containing:

A screenshot for generate key pair action can be seen below:

Depending on the RSA/DSA algorithm selected, the key size and the signature algorithm are different while for EC(DSA)/ECGOST3410 Parameter Specification is involved.

Manage Certificate Extensions

Certificate extensions are used to offer more information about the certificate by extending the original X.509 certificate standard information with additional identification information or information about the cryptographic capabilities and restrictions in usage of the certificate.

In order to be able to add extensions to the certificate, select the Certificate Extensions tab (the Version 3 option has to be selected in the Certificate Info tab. Version 1 certificates do not accept extensions, therefore the tab is disabled for version 1 certificates).

This tab offers the possibility to create a new set of extensions for the certificate, or load a set of extensions from a previously saved template. The extensions are represented in this dialog using a tree-like list, as it can be seen below:

The extensions of the certificate together with their items can be added in the tree list from the left side (as it can be seen in the above picture), while on the right side, the values of each added extension item can be set after selecting the item for which the value should be set from the left side tree.

Creating an extension

To create an extension, the following steps must be performed:

  • Right click on the extensions item from the extensions list;

  • From the contextual menu that appears, select one of the available extensions;

    CERTivity allows adding the following 8 extensions to a certificate:

    • Authority Key Identifier:

      This extension is used for identifying the public key corresponding to the private key used to sign a certificate. It is used where an issuer has multiple signing keys (either due to multiple concurrent key pairs or due to changeover). The identification may be based on either the key identifier (the subject key identifier in the issuer's certificate) or on the issuer name and serial number. For more details please see RFC 5280 - 4.2.1.1 Authority Key Identifier.

      CERTivity allows computing the value of the keyIdentifier field by deriving it from the public key (issuer public key) used to verify the certificate's signature. There are two available methods used by CERTivity for generating the key identifier:

      • 160-bit hash of the value of the bit string of the public key;

      • 64-bit hash of the value of the bit string of the public key.

    • Basic Constraints:

      This extension identifies whether the subject of the certificate is a CA (using the isCA field) and the maximum depth of valid certification paths that include this certificate (using the pathLengthConstraint field). For more details please see RFC 5280 - 4.2.1.10 Basic Constraints.

    • CRL Distribution Points:

      This extension identifies how CRL information is obtained. The cRLDistributionPoints extension can contain one or more DistributionPoint items. A Distribution Point consists of three fields, each of which is optional: distributionPoint, reasons, and cRLIssuer. Each of these fields is optional, but a DistributionPoint must not consist of only the reasons field; either distributionPoint or cRLIssuer must be present. For more details please see RFC 5280 - 4.2.1.14 CRL Distribution Points.

    • Extended Key Usage:

      This extension indicates one or more purposes for which the certified public key may be used, in addition to or in place of the basic purposes indicated in the key usage extension. In general, this extension will appear only in end entity certificates. For more details please see RFC 5280 - 4.2.1.13 Extended Key Usage.

    • Key Usage:

      This extension defines the purpose (e.g., encipherment, signature, certificate signing) of the key contained in the certificate. The usage restriction might be employed when a key that could be used for more than one operation is to be restricted. For example, when a RSA key should be used only to verify signatures on objects other than public key certificates and CRLs, the digitalSignature and/or nonRepudiation bits would be asserted. Likewise, when a RSA key should be used only for key management, the keyEncipherment bit would be asserted. For more details please see RFC 5280 - 4.2.1.3 Key Usage.

    • Netscape Cert Type:

      This extension is used for limiting the applications for a certificate. If the extension exists in a certificate, it will limit the uses of the certificate to those specified. The following values are available:

      • SSL Clent: the certificate is selectable when a server requests a certificate;

      • SSL Server: the Netscape Communicator will talk to a server (otherwise it will complain that the certificate is invalid);

      • S/MIME Client: the certificate can be used for S/MIME signing and encryption;

      • Object Signing: the certificate can be used for signing objects such as Java applets and plugins;

      • Reserved: this bit is reserved for future use;

      • SSL CA: the certificate can be used for issuing certificates for SSL use;

      • S/MIME CA: the certificate can be used for issuing certificates for S/MIME use;

      • Object Signing CA: this certificate is certified for issuing certificates for Object Signing.

    • Private Key Usage Period:

      This extension allows the certificate issuer to specify a different validity period for the private key than the certificate. This extension is intended for use with digital signature keys. This extension consists of two optional components, notBefore (the date from when the certificate can be used) and notAfter (the date until the certificate can be used). For more details please see RFC 3280 - 4.2.1.4 Private Key Usage Period.

    • Subject Key Identifier:

      This extension provides a means of identifying certificates that contain a particular public key. For more details please see RFC 5280 - 4.2.1.2 Subject Key Identifier.

      CERTivity allows computing the value of the keyIdentifier field by deriving it from the public key (subject public key) used to verify the certificate's signature. There are two available methods used by CERTivity for generating the key identifier:

      • 160-bit hash of the value of the bit string of the public key;

      • 64-bit hash of the value of the bit string of the public key.

    • Certificate Policies:

      This extension contains a sequence of one or more policy information terms, each of which consists of an object identifier (OID) and optional qualifiers. In an end entity certificate, these policy information terms indicate the policy under which the certificate has been issued and the purposes for which the certificate may be used. In a CA certificate, these policy information terms limit the set of policies for certification paths that include this certificate. For more details please see RFC 5280 - 4.2.1.4. Certificate Policies.

    • Policy Mappings:

      This extension is used in CA certificates. It lists one or more pairs of OIDs; each pair includes an issuerDomainPolicy and a subjectDomainPolicy. The pairing indicates the issuing CA considers its issuerDomainPolicy equivalent to the subject CA's subjectDomainPolicy. For more details please see RFC 5280 - 4.2.1.5. Policy Mappings.

    • Subject Alternative Name:

      This extension allows identities to be bound to the subject of the certificate. These identities may be included in addition to or in place of the identity in the subject field of the certificate. Defined options include an Internet electronic mail address, a DNS name, an IP address, and a Uniform Resource Identifier (URI). For more details please see RFC 5280 - 4.2.1.6. Subject Alternative Name.

    • Issuer Alternative Name:

      This extension is used to associate Internet style identities with the certificate issuer. For more details please see RFC 5280 - 4.2.1.7. Issuer Alternative Name.

    • Authority Information Access:

      This extension indicates how to access information and services for the issuer of the certificate in which the extension appears. Information and services may include on-line validation services and CA policy data. (The location of CRLs is not specified in this extension; that information is provided by the cRLDistributionPoints extension). This extension may be included in end entity or CA certificates. For more details please see RFC 5280 - 4.2.2.1. Authority Information Access.

    • Subject Information Access:

      The Subject Information Access extension indicates how to access information and services for the subject of the certificate in which the extension appears. When the subject is a CA, information and services may include certificate validation services and CA policy data. When the subject is an end entity, the information describes the type of services offered and how to access them. In this case, the contents of this extension are defined in the protocol specifications for the supported services. This extension may be included in end entity or CA certificates. For more details please see RFC 5280 - 4.2.2.2. Subject Information Access.

    • Inhibit Any Policy:

      This extension indicates that the special anyPolicy OID, with the value {2 5 29 32 0}, is not considered an explicit match for other certificate policies except when it appears in an intermediate self-issued CA certificate. The value indicates the number of additional non-self-issued certificates that may appear in the path before anyPolicy is no longer permitted. The inhibit anyPolicy extension can be used in certificates issued to CAs. For more details please see RFC 5280 - 4.2.1.14. Inhibit anyPolicy.

    • Name Constraints:

      This extension indicates a name space within which all subject names in subsequent certificates in a certification path MUST be located. This extension MUST be used only in a CA certificate. Restrictions apply to the subject distinguished name and apply to subject alternative names. Restrictions apply only when the specified name form is present. If no name of the type is in the certificate, the certificate is acceptable. For more details please see RFC 5280 - 4.2.1.10. Name Constraints.

    • Policy Constraints:

      The Policy Constraints extension constrains path validation in two ways. It can be used to prohibit policy mapping or require that each certificate in a path contain an acceptable policy identifier. If the inhibitPolicyMapping field is present, the value indicates the number of additional certificates that may appear in the path before policy mapping is no longer permitted. If the requireExplicitPolicy field is present, the value of requireExplicitPolicy indicates the number of additional certificates that may appear in the path before an explicit policy is required for the entire path. The policy constraints extension can be used in certificates issued to CAs. For more details please see RFC 5280 - 4.2.1.11. Policy Constraints.

    • Freshest CRL (a.k.a. Delta CRL Distribution Point):

      This extension identifies how Delta CRL information is obtained. The extension MUST be marked as non-critical by conforming CAs. For more details please see RFC 5280 - 4.2.1.15. Freshest CRL (a.k.a. Delta CRL Distribution Point).

    • Subject Directory Attributes:

      This extension is used to convey identification attributes (e.g., nationality) of the subject. This extension is defined as a sequence of one or more attributes. Conforming CAs MUST mark this extension as non-critical. For more details please see RFC 5280 - 4.2.1.8. Subject Directory Attributes.

    Each extension can be added only once. Therefore, after an extension is added, on the next right click on the extensions root node, on the pop-up menu only the remaining available extensions which have not already been added will be displayed.

  • If the new added extension contains subitems (like the Authority Key Identifier extension for example which contains Key Identifier, Authority Certificate Issuer, and Authority Certificate Serial Number) these can be added in the same way, by right clicking on the list item of the new added extension. A popup menu containing the available subitems will be displayed. In the same way as for extensions, some of the subitems can be added only once, so they will appear only once on the first popup menu when right clicking on the item for which they have to be added.

    Some extensions contain mandatory subitems (for example the "Is CA" field, from Basic constraints extension), which will be added automatically when adding the new extension item. Also, after creating the extension item, the popup menu containing the available subitems will be automatically displayed as a form of autocompletion.

    If the selected extension or subitem does not contain any more mandatory or optional subitems, in the right side of the dialog, a panel will be displayed allowing the input of the value of the extension or subitem. This panel will contain either a text field (for extensions and items which allow various textual input) or a list of checkboxes for the ones which only have certain defined values (like the Key usage extension).

  • For items which allow text input, to set the filled in value, press the Set value button.

After each extension or subitem added, as well as after each value set for an extension or subitem, the structure of the extension and the values are verified to ensure that they are valid according to the RFC 3280 and RFC 5280 standards. For the extensions to be able to be created, their structure and value has to be valid according to this standard. Otherwise, when trying to create the certificate, a message will be displayed informing that the structure or the values of the extensions are not valid, and asking if the certificate should be created without adding the extensions or to return to the certificate generation dialog for correcting errors.

Note

The validity state of the structure and content of the extension can be seen at any time at the bottom of the certificate structure list. For a valid structure, a green note will be displaying the message "Extensions structure is valid".

If the structure is not valid, due to missing mandatory subitems or invalid values set, the note will be displaying a red warning containing the message "Extensions structure is invalid". Also, under this note a table will become visible containing the additional information about each item which is invalid. The table contains the type of message (Error or Warning), the name of the extension item or subitem which is invalid, and an additional message containing the details of the error, as can be seen below:

Selecting a row in the table will trigger the selection of the extension item or subitem to which the table row refers to. If the selection of the row is done having the pointer over the last column ("Error" column) a popup dialog will also be displayed showing the full details of the error.

Field value auto completing

For some extension fields, the value can be obtained from the information from the certificate or which is to be set to the certificate in case of generating a new Key Pair (for example from the serial number, or the Issuer/Subject name), or by computing hash values on the public key from the certificate or the one which is created when generating a new Key Pair.

  • For Authority Key Identifier extension:

    • The value of the Key Identifier field is computed using one of the two methods (mentioned above) for generating the hash over the issuer public key.

      For generating a new Key Pair (containing a new self-signed certificate), the private - public Key Pair is usually generated when pressing the OK button. But, if the Key Identifier item is added for the Authority Key Identifier, a message will be displayed requesting to generate the public key earlier, so that its hash can be generated and used as a value for this field.

      If this request is denied, the Authority Key Identifier can still be added, but the value will have to be set by the user.

      Note

      This message will not be displayed when signing CSR files, because in that case both the public key of the issuer certificate and the public key of the resulting CA reply are generated at the time of adding extensions to the CA reply.

      By default when generating the public key and computing the hash over it, the hash will be 160-bit. To use the 64-bit hash, switch to the 64-bit radio button. The value from the text field will be replaced with the 64-bit value. Also, to use back the 160-bit value, select the 160-bit radio button.

      The radio buttons can be seen in the screenshot below:

    • The Directory Name of the Authority Certificate Issuer, in the case in which the Authority Certificate Issuer should be represented using a Directory Name, can be autocompleted at generation time using the name values of the certificate Issuer DN (which for self-signed certificates is the same with the Subject DN), if these fields have been completed in the Certificate Info tab. Only the name items for which there is a value added in the previous tab will be added. The rest can be added manually by right-clicking on the Directory Name node, and adding a name component from the remaining items in the popup menu.

    • The Authority Certificate Serial Number extension item can have it's value taken from the Serial Number field in the Certificate Info tab. If the serial number was not set, when creating the Authority Certificate Serial Number a message will be displayed asking to generate and set the Serial Number and also use that value for the Authority Certificate Serial Number. If this request is denied, then the value of the Authority Certificate Serial Number must be set manually.

  • For CRL Distribution Points extension:

    For this extension, the same mechanism for autocompleting values applies where Directory Name items are used, like the one mentioned for the Authority Key Identifier extension. The names are taken from the Issuer DN if they were added before creating the Directory Name item.

  • For Subject Key Identifier extension:

    The value of this extension can be generated automatically in the same way the Key Identifier item from the Authority Key Identifier extension can be generated (presented above). The only differences are that for this extension the hash is computed over the public key of the user certificate, not the public key of the issuer certificate.

Save extensions template

After creating one or more extensions, the structure of the extensions together with their values can be saved to a file as a template, so that it can be reused for other certificate generation. The template will be represented by an XML document.

To save an extensions template the following actions must be performed:

  • Click on the Save Extensions button;

  • If the extensions structure is not valid or the items contain invalid values, a warning message will be displayed asking if the template should be saved anyway although it is invalid. If the "No" button is pressed, it will return to the panel for adding extensions.

  • In the file chooser dialog that appears, type the name for the template. It will be saved in an XML document file.

Load extensions template

Extension structure templates previously created together with their values can also be loaded back from a file to be used for creating the same extensions for more certificates.

To load an extension template the following actions must be performed:

  • Click on Load Extensions button;

  • From the file chooser dialog that appears, select the template file to be loaded. The loaded extension structure will appear in the list on the left of the panel and will be validated.

View As XML

The extension structure can also be viewed in XML format. This XML format is the one in which the extension structure and values will be saved in the template file if this option is chosen.

The structure can be viewed in XML format at any time (either if the structure is valid or invalid), by clicking on the View As XML button. A dialog will open like the one below:

The XML structure can be copied to clipboard with a simple click on the Copy button, or by selecting the entire text and using the copy shortcut (CTRL-C).

The XML structure follows the tree like structure of the extensions list. The direct XML child nodes of the extensions root node represent the extensions. The items of each extension (when they are present) are represented as child nodes of each extension node. The name of the XML nodes are similar to the names of the extensions and their subitems in the ASN.1 representation (which can be seen for each extension in RFC 5280).

Mark extensions as critical

Extensions can be marked as critical or non critical. When an extension is marked as critical, it indicates that its value contains information of such importance that an application cannot ignore it. If a particular certificate-using application cannot process a critical extension, the application should reject the certificate.

CERTivity allows marking the extensions as critical. By default, after the extension item is created in the extensions list, the extension is considered to be non-critical.

To make an extension critical after its structure was created in the list, right click on the extension item, and from the popup menu that appears select Critical extension as it can be seen below:

After the extension is marked as critical, next to the extension item in the tree list the "[C]" symbol will be added, informing that the extension was marked as critical, as it can be seen below:

Also, in the right click menu for the extension item, the "Critical extension" menu will be checked.

To unmark an extension that has been marked as critical, right click on the extension item again, and from the popup menu that appears select again Critical extension (which now is checked) to uncheck it.

Note

Although all extensions can be marked as critical, the "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" (RFC 3280 and RFC 5280) recommends that some extensions should not be marked as critical. If an extension is marked as critical, the application which uses the certificate has to be able to process the extension, or otherwise to reject the certificate.

The extension creation may fail in the situation in which some of the extensions which should not be marked critical are marked so. For example, if the Authority Key Identifier extension is marked as critical (although the above mentioned profile does not recommend to be marked as so), if for the Authority Certificate Issuer an Uniform Resource Identifier is set, if the value of this URI does not have a valid form, the creation of the extension will fail. The same situation applies to the CRL Distribution Points extension.

The other extensions supported by CERTivity which the profile does not recommend marking as critical are Private Key Usage Period and Subject Key Identifier.

Delete extensions

The extensions and their subitems can also be deleted from the extensions structure. To delete an individual extension or subitem the following steps can be performed:

  • Select the extension or subitem to be deleted;

  • Right click on it, and from the popup menu, select Delete.

Or:

  • Select the extension or subitem to be deleted;

  • Press "Delete" key.

Also, to delete the entire structure, right click on the extensions item node, and select Delete all.

Prev Up Next
View Private Key Details Home Generate Secret Key