Symbian
Symbian OS Library

SYMBIAN OS V9.3

[Index] [Spacer] [Previous] [Next]



Root Certificate Management, Storage, and Client registration


Root Certificate Management and Storage


The file certificate store

To do a certificate validation a client (also known as an 'application') must have at least one certificate that it trusts directly - a root certificate. It's pretty clear that different clients are going to trust different certificates, for example, TLS might trust VeriSign's secure server root, but Software Install would not.

There is a single 'file' certificate store (certstore), CACerts.dat, initially populated with default root certificates, located in c:\system\data\ (or a private directory). When a certstore object is constructed it looks for the store in this location. If it cannot be found the original store is copied over from ROM.

A certificate is marked with zero or more UIDs, each of which identifies an application that trusts this certificate. These can be edited and the resulting entry put back in the store, this changes the trust settings for that certificate.


The certificate applications store

The certificate applications (certapps) store, certclients.dat, which is used by the file certstore, contains a set of zero or more clients. Each client consists of a UID and a human-readable name, and represents an application that requires the services of Certificate Management (certman). For example, TLS is a client, as is Software Installation. The word 'application' is used in its broadest possible sense; the UIDs do not have to be Symbian OS application UIDs, although this may be a sensible choice. Each certificate is marked as trusted by zero or more of these clients, this is what makes it a root certificate for that application.

The CCertificateAppInfoManager class (see below) provides functions to add, remove and list these UID/name pairs. A certman application can retrieve the UID/name pairs for all clients of Certificate Management. The TCertificateAppInfo class (see below) encapsulates the UID/name pairs.

[Top]


Client registration

Clients that use certificates register with certificate storage by providing a UID and a name. To reiterate, each certificate is marked with zero or more of these UIDs, indicating that it is trusted by that particular application. This enables a client(s) to mark a certificate as being trusted for use by a particular program.

In practice, known applications that use certification, such as a web browser or the software installer, will already be registered. Currently, the following applications/UIDs are defined:

Client/Application name UID Description

SWInstall

268452523, 0X100042AB

Certificate is suitable for software installation (SIS files)

SWInstallOCSP

268478646, 0X1000A8B6

Certificate is suitable for OCSP checking (SIS files)

MidletInstall

270506792, 0X101F9B28

Certificate is suitable for Java MIDlet installation, which includes OCSP checking

TLS/SSL

268441661, 0X1000183D

Certificate is suitable for SSL/TLS server authentication.

These UIDs are stored in certclients.dat; see the Location of the certstore and certapps store section below.

An application using the certificate validation interface needs to supply the appropriate UID to the certificate validation object, which uses this to select the subset of certificates that are trusted by that application: these form the set of 'candidate' root certificates.

For a client to work with certificate validation, it needs:


CCertificateAppInfoManager

The CCertificateAppInfoManager class provides the following functions for client registration:

When a certificate is added to the certstore it is added along with a set of trusters: this set can be edited subsequently. Then, when clients retrieve sets of certificates they can parameterise the request with a set of trusters, and only certificates trusted by those trusters will be retrieved. See:


TCertificateAppInfo

This simple class consists of a UID and a name. The UID does not have to be the application UID, but must be unique; it is anticipated that this can be ensured through the standard UID allocation scheme. Certificate storage does not check UIDs for uniqueness.

IMPORT_C TCertManClientInfo(const TUid& aUid, const TName& aName);
IMPORT_C TCertificateAppInfo(const TUid& aUid, const TName& aName);

IMPORT_C const TUid& Id() const;
IMPORT_C const TUid& Id() const;

IMPORT_C const TName& Name() const;
IMPORT_C const TName& Name() const;

[Top]


Location of the certstore and certapps store

These files are located in ROM on a phone. They are necessary for applications such as Software Install and SSL/TLS.

On a cold boot the store is copied over to system\data (or, on Symbian OS v9.0, to a private directory) on the device's internal RAM drive. Subsequently, certificate storage will look for the store on that hardcoded path. If the store can't be found there, the original will be copied from ROM.