Maintaining the rootstore
Activities
The following activies are needed for the rootstore:
- Add new roots, or update roots that have their validity extended
- Remove obsolete roots
- Remove roots for CAs that have become renegades
- Keep flags up to date.
- Add associations between roots and/or intermediates
- Add EV OID associations for roots that have been authorized for EV
- Remove EV OIDs for roots that no longer qualify (part of this is automatic).
Adding new roots
There are two occasions upon which a new root is added
- A new CA have asked to be added to the rootstore
- A CA already having roots embedded wants to add new roots.
In the first case, the CA first have to pass through a procedure designed to make
sure only real CAs get admitted to the rootstore.
In the second, the CA is already authorized, and no further vetting at that level
is needed.
Before adding a certificate it should be verified that the person submitting the
certificates is authorized to do so, then:
- Convert the certificate(s) to a C unsigned char array in
a headerfile, with an appropriate name for the file and the array. Several utilities
exist for this. Store the file in the modules/rootstore/defcert folder.
- Add a new version number to the rootstore_version.h file, and define SSL_Options_Version
to use it. This new version number will be used for each certificate added.
- Open the rootstore_table.h file
- At the end of the table (Which is encoded in the network modules const array systems)
add an entry for each certificate using the one of the following templates:
- DEFCERT_ITEM(certname, warn, deny, friendly, version) Adding a normal certificate
- DEFCERT_REPLACEITEM(certname, warn, deny, friendly, version) Updating a certificate
that have been installed earlier
- DEFCERT_ITEM_PRESHIP(certname, warn, deny, friendly, version) Adding a normal certificate,
but one that is to be preshipped with versions able to update from the online repository,
this is used to roots with a high market share, or that are vital for the installation
to be able to access off-line
- DEFCERT_ITEM_WITH_DEPEND(certname, warn, deny, friendly, version, dependencies)
Add a certificate with various dependencies
- DEFCERT_ITEM_WITH_DEPEND_PRESHIP(certname, warn, deny, friendly, version, dependencies)
Add a preshipped certificate with various dependencies.
The parameters are:
- certname: The name of the byte array containing the certificate
- warn: Warn the user about certificates signed by this certificate?
- deny: Deny SSL/TLS access to sites presenting certificates signed by this certificate?
Only used for certificates that will only sign client authentication certificates,
also there are now extensions that define this
- friendly: Optional name to be used in the certificate manager. Leave as NULL if
default name is to be used
- version: The version of the SSL data files this certificate was included in, as
created above. This is used to limit updates to just the certificates that are new
since the version that last wrote the certificate manager's filestorage.
- dependencies: Pointer to a structure that defines the dependencies of this certificate.
- Confirm that the certificate is being added to the correct storage.
- Verify the contact information for your contact at the CA as well as possible.
- To verify correct embedding of the certificate, phone the contact (do NOT use Skype
or similar internet phones), and request that he or she read aloud the SHA-1 fingerprint
(a digest of the entire certificate) of the certificates, and confirm that this
fingerprint matches the one calculated by Opera.While not perfect this provides
a reasonable assurance that the certificate was indeed provided by the CA.
- Once the certificate(s) are verified they can be added to the CVS and the changes
to the table can be commited, and an updated module be released.
Removing obsolete certificates
Certificates are only valid for a certain time. When removing or updating a certificate
the old include file declarations and the entry in the repository table is at least
commented out. Optionally they can be deleted, but having a trace of what certificates
have been included in the repository is most preferable.
Removing roots for renegade CAs
While this is a rare event (we hope) a CA may start issuing certificates that are
not thrustworthy. In such cases it may not be enough to just disable the root, it
may be necessary to forcibly remove the root in each installed client, as well as
marking the CA as untrusted.
In such cases:
- Disable the root as specified in the "obsolete" section.
- Go to the bottom of the rootstore_table file, inside the serverside section
- Add an include of the certificate's include file.
- For certificates that are to be deleted, add a DC_DELETE_CERT_ITEM(certname, "reason")
entry in DEFCERT_DELETE_cert_st explaining why the certificate is being deleted
- For certificates that er to be untrusted, add a DC_UNTRUSTED_CERT_ITEM(certname,
"shortname", "reason") entry in DEFCERT_UNTRUSTED_cert_st, with an appropriate descriptive
name and a reason for why it is untrusted (the latter is only stored in the file).
- Individual certificates may also be marked as untrusted, and in such cases they
are converted as descriped above.
This functionality will only work for client versions that have a remote update
capability.