Definitions

Basically, a certificate is a digital document used to verify that a public key belongs to the correct remote subject (a system, person, organization, etc.). Certificates are issued by trusted certification authority (CA) and are verified by the CA's digital certificate.

When sending data, the certificate owner uses the private key corresponding to its certificate to sign the information. The receiver can extract the public-key of the sender out of the certificate and uses this key to decrypt the information.

Certificate Attributes

A certificate has the following attributes:

• Subject name - The name of the certificate's subject and other identifying information, such as organization name and location.
• Subject public-key - The subject's public key.
• Issuer name - The name of the certificate's issuer together with additional information, such as organization and location.
• Issuer digital signature - The digital signature of the issuer CA.
• Validity period - The period for which the certificate is valid.
• Serial number - The certificate's serial number.

Additionally, RM adds its own certificate attributes:

• Revoked certificates - The subject certificates, signed by this issuer certificate, which are later declared untrusted for the remaining period of their current validity. This attribute is useful only for the issuer CAs.
• Certificate Properties - These properties bind specific information to the certificate, as an instance - certificate ID, user-friendly name, detailed description, etc. Third-party applications may provide such properties and further interpret them to deliver custom usability.

Certificate Chains

A certificate chain or certificate path is a sequence of certificates in which each one is signed by the next certificate in the chain. The last certificate is self-signed and is called root. This is the certificate that belongs to the Certificate Authority (CA).

Trusted and Own Certificates in RM

In RM, trusted are certificates that RM trusts in the context of certain Certificate Domain(s) (see the "RM Certificate Domains" section below). Own are those certificates which belong to RM, respectively their private keys too.

Revoked Certificates

Revoked is a certificate whose validity is canceled for some reasons before its expiration date. Revoked certificates, issued by certain CA, are arranged in time-stamped certificate revocation lists (CRLs), periodically published on specially allocated URLs. A certificate is identified by its serial number within a CRL.

Certificate Authentication in RM

RM uses certificate-based authentication in the following areas of its operation:

• SSL and HTTPS-based connection between RAS and RAC.
• Secure connection between the available OSGi devices and the Management Servers, provided by the mPRM Secure Transport, SSL/TCP Transport and the RM HTTPS Transport services. For details on those services, please refer to the "OSGi Device Management" documentation.
• Certificate-based user logins.
• TLS/SSL-based communication with the backend. As an instance , it is used by the HTTP server in the established HTTPS connections.

Certificates are managed by a module called Certificate Manager and kept into a storage, called Certificate Repository.

Remote Manager Certificate Domains

In RM, a certificate can belong to zero or more domains, which determine the RM security subsystems the certificate is trusted of.

By default , RM supports the following domains:

• mPRM RAS – The certificate will be used for authentication of remote access client (RAC) applications.
• mPRM TLS Server – The certificate will be used by TLS server for authentication in a TLS communication session.
• mPRM TLS Client – The certificate will be used for TLS client authentication in a TLS communication session.

RM creates a javax.net.ssl.SSLContext to represent the "mPRM TLS Client" domain and sets it to the javax.net.ssl.HttpsURLConnection of the JVM as the default SSL context. Therefore, all connections established with the HTTPS Client that use the default SSL context will use the one RM has set - the connections will use the own and trusted certificates available in the "mPRM TLS Client" domain and will perform all needed authentications with them.

RM also sets its own javax.net.ssl.HostnameVerifier as default to the javax.net.ssl.HttpsURLConnection. This hostname verifier skips the hostname checking of the HTTPS Client connections. It is activated when the mprm.https.client.replaceHostnameVerifier system property is set to "true" or is not present at all.

• mPRM Secure Transport – The certificate will be used for authentication in a secure communication between the OSGi devices and the Management Servers.

New domains can be added by third party applications. The only requirement is not to use the above mentioned symbolic names as they are reserved by RM.

Certificate Manager

Certificate Repository

The Certificate Repository is a Database Service which persistently stores certificates of trusted certification authorities (CAs) as well as own certificates on an RDBMS server.

Initializing the Certificate Repository

On RM initial startup, you can initialize the Certificate Repository in three ways:

• Use the default initialization RM offers. When initially started, RM automatically initializes the Certificate Repository by generating a default certificate into it. This certificate is applicable to mPRM TLS Server/Client and mPRM RAS domains.
• By importing a certificate and optionally its key. To do that:

1. Create an <rm_root_dir>/initial_config/certificates directory and place the certificate file in there. The file can have one of the following extensions: .cer, .crt or .pem.
2. Optional. Place the certificate key file at the <rm_root_dir>/initial_config/certificates directory. The key file must be named <certificate_name>.key, for example, the key file for mycertificate.cer will be mycertificate.key.
3. Optional. Create a certificate properties file and place it at the same directory. The certificate properties file must be named <certificate_name>.prs, for example the properties file for mycertificate.cer will be mycertificate.prs. In the properties file, you can set the domains where the certificate will be applicable and a CRL URL. Use the following properties:

• By importing a key store. Therefore, you can import all the certificates you need at once, and optionally certificate keys and certificate chains. To import a key store:

1. Create an <rm_root_dir>/initial_config/certificates  directory and place the key store file in there. The file can have one of the following extensions: .p12, .pfx or .keystore
2. Create a key store properties file and place it at the same directory. The file must be named <key_store_name>.prs, for example the properties file for mykeystore.keystore will be mykeystore.prs. You can provide the following information in the key store properties file:

• Specify the key store password in the following property:
  
  storepass=<key store password>

• Specify a password for all key entries, or a separate password per each key entry:
  • To specify a common password, use the following property:
    
    keypass=<key entry password>

• • To specify a separate password per each key entry, use the following property:
    
    keypass.<alias>=<key entry password>

• Optional. Indicate the key store's provider in the following property:
  
  keystoreprovider =<provider>

• Optional. Indicate the key store's provider type in the following property:
  
  keystoretype =<provider type>

• Optional. Set certificate domains and CRL URLs per each certificate in the key store:
  
  If the key store holds one alias, you can set certificate domains to each member certificate of the corresponding certificate chain as well as a CRL URLs. This is represented by the following content in the properties file:

If the key store holds more than one alias, you can set certificate domains to the certificate chain members of each alias, as well as CRL URLs. This is represented by the following content in the properties file:

The default RM initialization folder is <rm_root_dir>/initial_config and can be changed through the xmprm.initialConfig.dir system property. It roots the Certificate Repository initialization folder, which is configurable through the mprm.initialConfig.certificates.dir system property. To change the initialization folders of RM and the Certificate Repository, you can add these properties to the dafault.prs file located at the <rm_root>bin/mserver installation folder of RM.

Key Pair Holders

Key Pair Holders are modules that provide containers for public and private key pairs. Using a Key Pair Holder, applications can perform essential cryptographic operations, such as data encryption and decryption keeping the relevant private key in secret. Obtaining a certificate chain associated with a private key is supported as well.

Key Pair Holders register as OSGi services javax.net.ssl.X509KeyManager instances. The Certificate Manager creates a Key Pair Holder for each certificate domain. It is responsible for keeping the public and private key pairs of the own certificates associated with the corresponding domain.

Certificate Verifiers

Certificate Verifiers are modules that can perform verification on certificates with questionable authenticity on behalf of interested modules. Certificate Verifiers register as OSGi service javax.net.ssl.X509TrustManager instances.

The Certificate Manager creates own Certificate Verifier for each certificate domain. In case a Certificate Domain encounters a certificate, to which it cannot trust at once, the relevant Certificate Verifier additionally verifies this certificate.

PKS Store Type

Bosch Digital has introduced a special type of key store - Provisioning KeyStore or PKS. Stores of the PKS type are portable across different JVMs and therefore the choice of store type is not limited by the proprietary JSSE provider in the JVM. A PKS store can contain trusted entries as well. You can generate such a store in the console by exporting a keystore with a collection of certificates from the Certificate Repository (see "Exporting a Keystore" in the Certificate Management User Guide).

Certificate Manager Service

The Certificate Manager service performs the following functions:

• Provides access to the certificates stored in the Certificate Repository.
• Informs all interested applications for changes that occur in the Certificate Repository.
• Provides cryptographic functionality, like finding a certificate's issuer, generating Security Context bundles, retrieving certificate properties, etc.

Revoked Certificates Management

As it was mentioned earlier, an issuer certificate can have zero or more revoked certificates signed with it. The Certificate Repository does not preserve the content of revoked certificates, but keeps only their serial numbers.

Using CRLs to acquire information on revoked certificates is a typical case, however RM allows its administrators to explicitly proclaim certain certificates as revoked within the RM system. Both of these mechanisms can be used simultaneously.

In case a certificate has a CRL distribution point, RM automatically retrieves the CRL's URL when the certificate is imported. Then RM sets this URL as a Revocation URL for the newly-imported certificate.

By default, RM rejects all certificates with inaccessible CRLs. This is configured through the mprm.certman.crlIsAlwaysOK system property in the default.prs file located at the bin/mserver RM installation directory.

Access Rights

The certificate manager restricts access to operations on stored certificates:

• View certificates - The right to view (without changing) the certificates in RM is granted only to members of the Permission - Certificates - View user group. However, the members of this group are not allowed to view the certificate private keys.
• Modify certificates - The right to modify the certificates in RM, that is, change their trusted levels, permissions or revocation status, is granted only to members of the Permission - Certificates - Modify user group. By default, these are the users who can administer certificates as well as the members of the ServiceProviders group.
• Administer certificates - The right to retrieve the key pairs of certificates is granted only to members of the Permission - Certificates - Admin group. By default, these are the members of the administration group, hence, the gateway operators.

User Interface

You can browse the certificates stored in the RM database as well as details about them through the Certificates dashboard view of console. See the Certificate Management document from User Guide.

References

• FAQ section on the RSA Security Web Site.
• RFC 2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile.