Getting your root certificate included in Opera
Last update: 2012-10-18
Opera Software takes an active part in the work to standardize the processes which safeguard the integrity and credibility of security certificates.
- On this page:
- Specification for X.509 root certificates to be included in the Opera browser
- Root certificate delivery and verification
- Test certificates
- Enabling an Extended Validation (EV) root certificate in Opera
- General Information
Specification for X.509 root certificates to be included in the Opera browser
This specification is based on the CA/Browser Forum guidelines for extended validation certificates and current best practices. The purpose of certificates included in the Opera browser should be:
- SSL/TLS site certificates
- SSL/TLS client certificates
- Object signing (Java)
In order to be included in the Opera browser, a root certificate must fulfill the following:
Requirements
- The Certification Authority must document a satisfactory audit by a recognized practicioner.
- The root certificates must comply with the RFC 3280 specification.
- The certificates issued by the CA must support the CRL extension and must point to a HTTP location that is publicly accessible. If one certificate in a chain specifies a CRL extension, all certificates must specify a CRL extension or OCSP for end certificates.
- We recommend support of OCSP for end certificates. The responder MUST support the HTTP GET request method (RFC 5019).
- Intermediate certificates should specify AIA issuer url FDQN names.
- The root certificates must have an expiration date more than 3 years in the future.
- All new certificates from the CA should use a minimum 2048 bit keylength, and should be signed with SHA-256, but may be signed with SHA-1. MD5-based signatures are no longer allowed.
- Certificates signed by the root certificates must have a significant presence on the public Internet.
- Opera Software must be provided with test certificates as specified below.
- All documents in other languages than English or Norwegian must be accompanied by a legal translation.
Acceptable audit practicioners
WebTrust for CA
The WebTrust program for Certification Authorities is based on the relevant international standards and is acceptable for all countries for which there is a properly accredited auditor.
ETSI TS 101 456 v1.4.3 and ETSI TS 102 042 V2.1.1
The ETSI TS 101 456 v1.4.3 and ETSI TS 102 042 V2.1.1 are based on EU directives and international standards. It is acceptable to all countries in the EU/EEA and countries that have the necessary legislation in place to support the procedures required for an ETSI audit.
Opera Software will accept a WebTrust for Certification Authorities audit, an ETSI TS 101 456 v1.4.3 (or newer), or an ETSI TS 102 042 V2.1.1 (or newer) audit issued by properly accredited auditors.
Government CAs
CAs that are operating as part of a national government may be audited by a government auditor, according to the WebTrust program principles, ETSI TS 101 456 v1.4.3, ETSI TS 102 042 V2.1.1 guidelines.
Application procedure
An entity that wishes to have root certificates included in the Opera browser should send the required information by mail to the following Opera postal address.
Required information
- The official registered name of the entity, the physical location (street address), the postal address, and the type of entity:
- Companies should specify the company type and where the company is formally registered.
- Government agencies and other state organs should specify their legal status and the chain of responsibility.
- Other entities should explain their legal status and official registration details.
- Please include the following information:
- The full name, e-mail address and telephone number of the primary contact
in the applicant organization
- An alternate contact at the same or higher level of authority
- A role email address that is always configured to forward messages to the
correct individuals who handle contact with the browser Root Certificate programs
- Documentation to establish credentials as a bona fide Certification Authority. See the requirements below to document this.
- Provide answers to the following questions for each root certificate requested to be included:
- Who are the target users for certificates signed by this root certificate?
- If it is not the first certificate you want to include, why is an additional certificate necessary?
- How will you verify the identity of those requesting certificates signed by this root?
- What is the URL to the certificate practice statement for this root?
- Which third-party audits have your CA practice undergone?
- What is the public HTTPS URL where certificates you have issued can be tested and verified?
- Have the client certificate issuing systems been tested with the Opera browser on all relevant platforms?
- What is the rollover policy when roots expire?
- In the case of a purchased root, the history must be documented.
- Authorized copies of the audit report confirmation letter
- For ETSI and Government Audits:
- All information necessary to check the auditor's accreditation, up to and including the national agency accrediting the auditor, including information about how to get verification from official and authoritative sources
- Optionally:
- HTTPS URLs to WebTrust seal files, or an equivalent online repository for ETSI accredited auditors, to speed up the audit verification process (It is recommended that the secure websites present Extended Validation certificates, but the certificate must chain to a root recognized by the newest version of Opera for desktop.)
Postal address
Opera Software ASA
att: Rootstore Services
Postboks 4214 Nydalen
NO-0401 Oslo
Norway
Root certificate delivery and verification
Sequence of Events
After you have met all the criteria for having your root certificates included in the Opera Browser, and received a reply stating that the criteria are met from Opera Software ASA, please send the following to our postal address provided below:
- A letter on your official letterhead signed by one or more persons who together have the legally binding signature of your organization.
- The letter must indicate that you accept the responsibility for certificates issued under the roots to be included in the Opera Browser, and that you will notify Opera Software immediately if one or more certificates need to be invalidated or recalled.
- The letter must state the certificate subject name, validity dates, and SHA-1 fingerprint for each certificate.
- Include the audit report.
Postal address
Opera Software ASA
att: Rootstore Services
Postboks 4214 Nydalen
NO-0401 Oslo
Norway
Please note:
- Opera Software ASA will require proof of the authenticity of the signatures from another source, such as a public notary or government agency. It must be possible for us to verify the validity of this source.
- We will want to verify the SHA-1 fingerprint over some alternate communications channel, for example by making a telephone call to the contact person.
Test Certificates
The testing certificates required by Opera should be submitted using your normal procedure for issuing certificates signed by your roots.
- The certificates should be made to Opera Software Quality Assurance.
- We require one certificate for the domain ca.opera.no where ca is your domain, and a signing certificate for our internal domain lab.osa.
Enabling an Extended Validation (EV) root certificate in Opera
EV enabling a root embedded in Opera requires that a CA has passed an EV audit as specified by CAB forum (http://www.cabforum.org). An authorized copy of this audit must be sent to Opera.
When applying for EV status for already embedded roots:
- Mail the information to your contact in Opera.
- Describe the root you want EV activated.
- You should send the EV audit to the postal mail address below, as we currently have to rely on paper archives.
If you apply for EV enabling at the same time you request a certificate to be included in the rootstore, specify that you want the root EV enabled, and include the EV audit with your rootstore request.
Postal address
Opera Software ASA
att: Rootstore Services
Postboks 4214 Nydalen
NO-0401 Oslo
Norway
General Information
The cost of getting a certificate included
Previously, Opera Software ASA did the work included in the CA audit and charged a fixed sum for it. With standard audits the burden for Opera is much smaller, and we have decided not to charge for our work. The cost of the audit and other necessary documentation will vary. Please check with your auditors to get a quote.
Audit requirements
The burden is on the CA to prove WebTrust or ETSI compliance. Your auditor should state whether the audit meets the WebTrust or ETSI criteria in the audit report.
Audit renewals
The auditor should state the validity in the report, but it will under no circumstances be valid for more than 12 months. If the audit is not renewed in time, your root certificates will no longer be acceptable for inclusion in Opera and may be removed on short notice.
How long is the delay before the certificate is included?
This will vary a lot depending on how soon the different authorities can verify the documents we receive. Typically, the scrutiny by the auditor will take most of the time. With a valid audit, verification time will depend on how long it takes to verify the auditor, and that the audit is valid according to WebTrust criteria.
Opera accepts root certificates all year, and there are no deadlines for the desktop browser. After your root certificate has been accepted and included, it will be available almost immediately in versions which use the Opera implementation of the SSL/TLS protocol.
Please note that this does not apply to many versions of Opera running on non-PC devices. For such versions, certificates may be controlled by the hardware manufacturer, or they may be embedded without any provision for upgrades.
When a CA or parts of their assets have been taken over
If you have purchased the roots of another CA, it is important to document the transactions in detail. As a general rule, intermediates should not be embedded. In the case that the assets of one CA have been split between several purchasers, it will be possible to make exceptions if the documentation is sufficient.