You can find the current list of countries with export restrictions here: swisssign.com/en/support/exportbeschraenkungen

Intermediate certificates

Every SwissSign end user certificate is signed by a SwissSign intermediate certificate. The intermediate certificate itself is signed by a root certificate. For example, to ensure that a certificate is considered trustworthy, it is important that the certificate chain is available on the web server. Almost all operating systems and applications come with the root certificate pre-installed, but the intermediate certificate(s) must be installed case by case. The end certificate is either downloaded from swisssign.net (for the previous SwissSign CA) or ra.swisssign.ch (for the new SwissSign CA) with the entire certificate chain, or the intermediate certificate is installed later on. 

Root certificates

Every SwissSign end user certificate is signed by a SwissSign intermediate certificate. The intermediate certificate itself is signed by a root certificate. For example, to ensure that a certificate is considered trustworthy, it is important that the certificate chain is available on the web server. Almost all operating systems and applications come with the root certificate pre-installed. But you still might need to install root certificates for special applications. The end certificate is either downloaded from swisssign.net or ra.swisssign.ch with the entire certificate chain, or the root certificate is installed later on. 

The root certificate is the anchor of trust for a PKI. Using a root certificate implies that the user instance accepts all certificates issued by the CA in question.

More information about CA usage, organisation, functions, methods and processes can be found in the SwissSign Certificate Policy (CP) and Certification Practice Statement (CPS): repository

Certificate revocation lists

Revoked or withdrawn certificates are published on a so-called Certificate Revocation List (CRL) or kept in an online service that provides up-to-date information about the validity of a certificate online over

“Online Certificate Status Protocol” (OCSP).

Just like in the physical world, it is also dangerous in the digital world if you lose a key or if the key becomes invalid, such as when an employee departs the company. Therefore, keys/certificates that need to be blocked to prevent damage are reported repeatedly. As with every CA, SwissSign publishes these keys/certificates in certificate revocation lists (CRLs).

The CRL contains all the serial numbers of certificates that have been revoked, i.e. declared invalid before the certificate lifetime has expired. The certificate status check loads the list from a public URL and searches it for the serial number of the certificate to be checked. If it is included in the list, the certificate is revoked; otherwise, it is valid.

Signature certificates that have been revoked stay on the CRL even after the expiry date specified in the certificate, because it is important for signature validation to know when a certificate was revoked.

CRLs are usually updated at regular intervals. As with certificates, the CRL’s lifetime is specified in the CRL itself. This lifetime is significantly longer than the issuance frequency (at least twice a day) would suggest. This means ‘fault majeur’ is also covered. CRLs can be cached locally and enable offline certificate status querying. The connection between the certificate holder and the relying party is not disclosed to the CSP. However, there is a relatively high degree of inaccuracy in a certificate’s status query.

One alternative is the OCSP online validation service, which provides real-time information about a certificate’s validity. High CA performance is important when using the OCSP. SwissSign CA ensures this high performance and also only uses its own Swiss-developed software for OCSP. Online status checks are typically used where timely certificate verification is important, such as for financial transfers.

All of our root CA certificates, intermediate CA certificates and certificate revocation lists (CRLs) can be downloaded from https://www.swisssign.com/en/support/ca-prod.html.

According to the CP/CPS, the certificate revocation list file for certificates (CRL) must be updated at least every 24 hours. However, SwissSign updates it much more frequently than this – every hour.

Generally speaking, a CRL file is valid for ten days, so it contains the note ‘Next update on …’ (creation date + 10 days). This is due to the regulation in case of force majeure. Here, in the event of a system failure, the certificate revocation list file should be updated again after ten days at the latest.

My operating system or application is displaying errors, or I don’t know how to install the certificate properly.

SwissSign covers common issues and how to solve them in its FAQs and documentation. Unfortunately, we cannot provide direct support for this. SwissSign AG’s core competence is creating standardised, trustworthy certificates. Since SwissSign does not develop applications or operating systems, it purposely refrains from providing support for applications and operating systems.

However, one of our partners may be able to offer you assistance with their application: SwissSign partners

SwissSign’s root certificates are installed in the most commonly used browsers. Update your browser to the latest version and install the latest root certificates from the Windows update page. 

Information about the compatibility and distribution of SwissSign root certificates can be found here: SwissSign | Compatibility

SwissSign allows you to generate your own key pair – private and public keys – with all services. The key must be at least 2,048 bits long.

Also, your web server may not send the full certificate chain to clients. You can solve this problem by using the ‘SSLCertificateChainFile’ function in the Apache configuration.

With SwissSign SSL certificates, you get unlimited server licenses. Unlike most other SSL certificates, there are no usage limits on your SwissSign SSL.

Certificates including a private key (.p12, PKCS#12)*

*This procedure is not suitable for SSL certificates! 

.p12 or PKCS#12 formats contain a public certificate and the private key (password-protected). The .p12 or PKCS#12 files are used for installation in email programs, operating systems and web servers, for example.

For web servers, the entire certificate chain must be installed. The CA that issues the certificate typically trusts a higher-level CA, which in turn trusts the SwissSign root certificate, for example. Only the certificate of the SwissSign root CA is recognised by all browsers. You can download the certificates for the intermediate CAs from the Download page and then install them. This only applies to people who are installing a web server, not end users.
 

Certificates without a private key

• .cer: DER- or Base64-encoded
• .crt: DER- or Base64-encoded
• .pem: Base64-encoded certificate enclosed by ‘-----BEGIN CERTIFICATE-----’ and ‘-----END CERTIFICATE-----’
• .p7b (certificate chain): Base64-encoded certificates in ASCII format (e.g. for Windows OS, Java Tomcat)
• .p7c (certificate chain): PKCS#7-signed data structure without data content, only with certificate(s) including the entire certificate chain (e.g. for Windows OS, Java Tomcat)
• .pem (certificate chain): Base64-encoded certificate including entire certificate chain (e.g. for Apache and similar platforms)

The .pfx format is congruent with the .p12 format. Download the .p12 format and rename the file’s extension to .pfx.

Unfortunately, SwissSign cannot help you if you lose or forget the password for the private key. The password cannot be recovered or reset. The only thing you can do is apply for a new certificate and keep that password safe.

• When you create a CSR (certificate signing request) in the Synology system, this will also create the key pair on the Synology server.

• Once the certificate has been issued, download it from swisssign.net in .pem format. All the other formats can trigger error messages, such as: ‘The file encoding must be saved as UTF-8.’

• Download the intermediate certificate (type G22) from the Download page

• You can now load the ‘private key’ files (generated locally), as well as the certificate in .pem format and the intermediate certificate in .pem format, on the Synology server.

There are two possible reasons for this:

• You forgot to install an intermediate certificate when setting up SSL encryption or in email systems. See the FAQ ‘My certificate is not running on my operating system or browser, even though SwissSign supports them’.

• The customer is running an ‘SSL Inspection’ in their proxy. This functionality breaks the encrypted connection and checks the communication for unauthorised content, or even malware, during download. SSL Inspection usually works with untrusted, proprietary certificates. This affects not only sites with SwissSign certificates, but also other sites too. The solution is to configure the page in question out of the proxy.

Often, these problems are not caused by missing or faulty root certificates in the operating systems or browsers, but rather by forgetting to install an intermediate certificate when setting up an SSL encryption or even in email systems.

Certificates are organised hierarchically. The certificate itself trusts an intermediate certificate and, if necessary, this trusts another intermediate certificate, and so on. Finally, the intermediate certificates also trust the root certificates listed in the browsers and operating systems. Since the browsers and operating systems only contain the root certificates, if there are no intermediate certificates, the chain of trust is broken.

In the Windows environment, these problems occur less frequently because Microsoft Windows or the Windows browsers try to store intermediate certificates temporarily as soon as a page with a correctly installed SwissSign certificate, for example, has been accessed once. This intermediate storage is then automatically used if the intermediate certificate was not installed correctly, and the user does not even notice the ‘error’.

With Linux, on the other hand, the missing configuration is immediately noticeable. The solution is to download the entire certificate chain and install the certificate chain including intermediate certificates:

Instructions for previous CA (swisssign.net):

• To do this, click on the link you received when the certificate was issued to download the certificates. Alternatively, you can also search for your certificate on swisssign.net and then click on the ‘Download’ button.
• In the download formats available, select the file with the extension .p7c or .pem (entire certificate chain). All other downloads – including the .p12 file – do not contain intermediate certificates.

Instructions for new CA (ra.swisssign.ch):

• To do this, click on the link you received when the certificate was issued to download the certificates. Alternatively, you can also search for your certificate on ra.swisssign.ch under the ‘Orders and certificates’ menu.
• You can then download the certificate:
  • In the PEM or Base64 format
  • Directly in the DER format
  • As a certificate chain (PKCS#7 format)

Before an SSL certificate can be issued, a key pair and a technical certificate request – a certificate signing request (CSR) – must be created.

• (Java) KeyStore Explorer

There are various tools that can be used for reformatting. For example, the Windows Certificate Viewer allows you to save a certificate in the following formats:

• Directly in binary format (DER – ‘Distinguished Encoding Rules’)
• Format encoded as text file (Base64 or PEM – ‘Privacy Enhanced Mail’)
• In PKCS#7 format (p7b or CMS – ‘Cryptographic Message Syntax’)

According to regulations, SwissSign is obliged to regularly revalidate active certificate attributes. If a difference between the certificate attributes and the official register is found, SwissSign is obliged to adjust this data in the certificate. 

The certificate holder, for his part, is obliged to report any changes to the address or organisation name to SwissSign within 3 working days without being asked to do so. Furthermore, he is obliged to revoke incorrectly issued certificates within 120 hours.

Revocation is a process that declares certificates invalid or blocks them. Revoked certificates are kept on certificate revocation lists (CRLs).

When an encryption certificate is revoked, it’s very important that you still keep the corresponding private key. You will still need it to decrypt data you encrypted using this old or revoked certificate.

When a signature certificate is revoked, you can delete the private key, as you will no longer be able to use it for a valid digital signature.

The reasons to revoke a certificate or declare it invalid include:

•  The user has forgotten the password for the private key.
•  The key material is no longer secret.
•  The information in the certificate is no longer up to date (e.g. email or leaving the organisation).

SwissSign certificates can be revoked in various ways:

For online shop customers and customers using the previous MPKI:

1. Online revocation: this is an option if you requested the certificate via a technical user account on swisssign.net. 

2. Online revocation: you can revoke certificates online at swisssign.net, provided you still have the private key or the revocation code. The code can be found in the approval email for this certificate. Please go to swisssign.net and, without logging in, enter in the ‘Licence:’ search field the certificate licence number you received when you purchased the certificate. The certificate will then be shown. Then click on the ‘Declare invalid’ button to revoke the certificate using the revocation code in the approval email. 

3. Offline revocation: alternatively, you can request that SwissSign carry out the revocation. The offline revocation form is available for this purpose. Please note that there is a charge for this service.

For customers using the new SwissSign CA/MPKI solution:

1. Online revocation: if you have applied for your certificate on ra.swisssign.ch, you can revoke it directly in the MPKI. Please proceed as described in the RA operator’s manual.

2. Offline revocation: alternatively, you can request that SwissSign carry out the revocation. The offline revocation form is available for this purpose. Please note that there is a charge for this service.

Either of these.

Certificates cannot be blocked temporarily (suspended).

SSL and email certificates: yes, these will be removed from the CRL after they expire.

Signature certificates: no, these remain in the CRL even after expiry to also ensure subsequent verification of a signature.

No, technically the certificate must be reissued when the content is changed.

Yes, you will receive an email notification 30 days before your SwissSign certificate expires.

You’ll need the corresponding private key to decrypt the data. Make sure that your old encryption certificate is still imported in your browser. This is the only way of decrypting data that was encrypted with your old certificate.

If the certificate no longer exists in your browser, log in to your SwissSign profile and download the certificate again. To do this, you will need the 16-digit password that you entered when creating the certificate.

Generally speaking, a certificate cannot be renewed. When a certificate is issued, it is given a fixed term, so, when it expires, you must apply for a new one. To do so, we need to check whether the content of the desired certificate is still valid.

In principle, it is possible to purchase an email certificate for a team account. However, this is still a personal certificate and requires a key holder.

The CP and CPS regulations apply here. These provide for the following:

• If the certificate was purchased as a gold certificate, the designation ‘pseudo:’ must be used instead of the first name and surname (pseudonym certificate). Example: pseudo: Sales Team

• For silver certificates that are only validated by email, any email address can be certified, provided that it has been verified that this email address exists.

Encryption of the email takes place with the help of the recipient’s certificate. Therefore, it is necessary that the sender receives the recipient’s certificate. This can be done manually or by using a corresponding secure mail gateway to collect the certificates from incoming emails.

Emails are encrypted with the recipient’s public key and decrypted with the recipient’s private key.

• There is a risk of losing certificates or the password for the private key. The emails encrypted with this certificate can never be read again by anyone.

• Certificates are renewed, but someone forgets to install the expired certificate as well. All stored emails encrypted with this certificate can no longer be read.

• An employee leaves the company or is absent for an extended period of time. Their emails cannot be read by anyone else.

• A virus or Trojan horse is sent using an encrypted email. Since there is no antivirus program that can scan an encrypted email, the virus or Trojan horse can penetrate unchecked. So, in this case, encryption can actually be a security risk.

The digital signature of a signed email is sent as an attachment. This attachment is automatically checked by the recipient’s email program. However, with most webmail providers such as Gmail or Hotmail, the signature is only displayed as an attachment with the file name smime.p7s without a signature check being carried out.

The email client classifies the issuer of the certificate as untrustworthy. This can be remedied by designating the issuer as trustworthy. Usually, the manufacturers of these programs take over this task by means of their root store programs.

By entering the issuer SwissSign as a trusted root. This means answering ‘Yes’ to the question ‘Do you want to trust the issuer?’ If you use a company computer, please contact your IT Support team.

Very often, our customers need a certificate to authenticate themselves on (log in) to a website.

The Pro S/MIME Email ID Gold certificate with authentication is intended for this kind of TLS www client authentication. It can also be used for email encryption and signing.

Please refer to the information on the following website: Managed PKI Service | SwissSign

To access your new MPKI, you need a SwissID login with corresponding two-factor authentication.

Please note that you must use the email address you specified in the order documents for your MPKI to log in.

You will find step-by-step instructions on how to create your SwissID here. 

Make sure that you have completed the steps for onboarding to the SwissID. 

Make sure that the SwissID has been registered with the same email address as indicated in the contract documents under the heading ‘RA operators’.

If necessary, your identification was forwarded to our back office for manual verification. You will receive an email as soon as the identification process has been completed successfully.

Yes. Send us the scanned and, if necessary, signed contract together with all the application documents to [email protected].

Alternatively, you can also send us your order by post as in the past:

SwissSign AG
Sales & Partner Management
Sägereistrasse 25
8152 Glattbrugg, Switzerland

SwissSign will confirm receipt of the order by email.

The submission of the ‘Contract and order for managed PKI services’ document will be deemed a binding order for a service subject to payment. The contract term and billing period begin on the date the order is placed.

The term of the managed PKI service is always one year and is automatically extended by one year if the contract is not terminated. If the contract is terminated, the certificates that are still active are withdrawn (revoked) on the termination date.

Domain specifications

The SSL or email domains are specified without assignment to a special certificate type. This means that you can later issue any SSL certificate you have ordered for all the named SSL domains. Similarly, the ordered email ID certificates can be issued for all named email domains.

Domain access permission

You prove your access permission by publishing a random value (secret) (in the DNS), which you obtain using the MPKI access.

Publication of certificates

SwissSign maintains a general directory of all published email certificates (accessible via LDAP protocol) at directory.swisssign.ch. This directory is public and can be thought of as a type of phone book. This is particularly useful for encrypted email communication, as your communication partner can use your public key in the certificate to encrypt the messages sent to you.

The public directory can be integrated directly into the email programs by entering parameters to perform encryption within the email programs by automatically retrieving the certificates.

If you do not want your certificates to be listed in the directory, select the ‘I do not want to publish my certificates’ option. You can also change this setting at a later date for a fee of CHF 150 or EUR 135.

The LDAP parameters are:

• Directory: directory.swisssign.ch.
• Search base: ‹o=SwissSign AG,c=CH›.

DV SSL Silver certificates

DV or Silver-level certificates are designated as domain-validated. Only the email or web server address is entered in the certificate. They can also include the organisation name. Encryption and signature are possible with email certificates, but not authentication. DV-level certificates are included in DV, OV and EV MPKI products.

OV SSL Gold certificates

OV/Gold-level certificates are designated as organisation-validated or person-validated. There is an organisation entry and, in the case of email (S/MIME) certificates, a person entry in the certificate. OV-level certificates are included in OV and EV MPKI products.

EV SSL Gold certificates

You can also issue EV SSL Gold certificates for your company as part of the managed PKI. They are thoroughly organisation-validated. EV-level certificates are included in the EV MPKI product.

Please note that a separate order or declaration of acceptance must always be submitted for certificates with an organisation entry.

To access your MPKI, your SwissID must be raised to a higher level of trust. You can find out how to do this by following the link below, which will help you to verify your identity step by step:

https://www.swisssign.com/en/support/dokumentationen/ra-operator-onboarding.html

Creating a SwissID account only takes a few minutes. It is important that you, as an MPKI operator, always use the e-mail address that was entered in the MPKI order in the section "RA operators". Then please follow the step-by-step instructions under the following link:

https://www.swisssign.com/en/support/dokumentationen/ra-operator-onboarding.html

If you suddenly can no longer log in to your MPKI as an MPKI Operator, this may be due to the fact that the last verification of your identity took place more than a year ago and therefore a re-identification is necessary. Please note that you do not need to create a new SwissID account and can start the identification process directly on the SwissID app. Start directly in chapter 2 of the step-by-step instructions under the following link:

https://www.swisssign.com/en/support/dokumentationen/ra-operator-onboarding.html

The times apply from receipt of the application documents and can only be complied with if all documents are complete and correctly issued.

Issuance speed for SSL certificates

• DV SSL Silver (single-domain and wildcard): within minutes
• OV SSL Gold (single-domain, multi-domain and wildcard): up to two working days
• EV SSL Gold EV (single-domain and multi-domain): five to ten working days

Issuance speed for S/MIME Email ID certificates

• Personal S/MIME Email ID Silver: within minutes

If you would like to obtain your certificates more quickly in the future, we recommend our MPKI services.

After purchasing your certificates from the swisssign.com online shop, please proceed as follows to obtain them:

• Log in to your user account.

• Select ‘Certificates’ and start the activation of the desired certificate by clicking on ‘Issue’ behind the corresponding entry.

• You will now be taken to the technical application for your certificate. To do so, follow the instructions in the application process.

• Once your application has been reviewed and accepted, you will receive an email with the link to download your certificate.

1. Log in to your online shop user account at swisssign.com.

2. Go to the ‘Certificates’ tab and open the desired entry.

3. The codes are displayed there. Click on ‘Share’ to copy the correct link.

4. Share the link with the other person.

5. The other person can now directly apply for the technical certificate using this link. They do not require a shop account for this.

You can enter the old licence codes on the enrolment website: portal.shop.swisssign.com/enrollment

The high security standards in the certificate business require that you obtain the signatures of the authorised persons again for a further certificate request and send them to us together with the corresponding copies of all IDs/passports.

To simplify the process when purchasing multiple certificates, you can be authorised by the responsible persons in your organisation: authorisation form (PDF, 106 KB). Please quote this authorisation with every order or enclose a copy.

Do you need certificates on a regular basis? Then you should consider our managed PKI certificate service, which also offers attractive volume discounts.

Please contact our support.

1. Log in to swisssign.com.

2. Search for the relevant request in your account.

3. Reprint the form.

To revoke your certificate from our online shop, you will need the revocation link from the email in which it was issued.

The timestamping service (TS) is the service provided by a CA that provides a certificate with the date, time and a signature of the CA, stating that certain digital data existed at a certain point in time. The SwissSign timestamping service complies with Swiss law (ZertES).

Digital timestamps are mainly used for archiving documents with precise timing or for labelling business documents such as contracts. Furthermore, Swiss law stipulates that a qualified signature is only equivalent to a handwritten signature if it is accompanied by a ‘qualified’ timestamp. The SwissSign timestamps can be used for workflow and archiving solutions. Although each electronic signature already contains a time (local system time), it can be useful to include an externally authenticated time with the data and documents. This makes it possible to easily and transparently prove at any time that the corresponding data record existed at a certain point in time and has not been changed since the exact time of stamping (integrity).

Usage: for example, in solutions for the implementation of legal requirements such as the Swiss Business Records Ordinance (AccO/GebüV), compliance regulations such as SOX, Basel II or industry-specific quality frameworks such as GMP.

The timestamp is technically a signature of the provider that contains a trustworthy time. This timestamp is generated through the Timestamping Authority (TSA) in accordance with RFC 3161. The RFC 3161 protocol requires that the request contain the hash value, which is then signed by the TSA. This ensures that the TSA service does not know anything about the content of the timestamped documents.

For more information, click here.

The reason for this is the adaptation of the timestamping service to the new security requirements and the resulting increase in the size of the response to the Adobe program by a few bytes. Adobe is not equipped for this in its normal configuration, so it recommends increasing the iSize in the registry.

The following patch for Adobe Reader DC serves as an example. Please save the following text as the file ‘fix_adobe.reg’ and double-click to make the change to the registry. It is advisable to back up the registry beforehand. Remember that the registry file is always specific to the Adobe version and, therefore, the text may need to be modified. E.g. may the part below that reads «Adobe Reader» be replaced by «Adobe Acrobat».

For Adobe Reader:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Adobe\Acrobat Reader\DC\Security\cASPKI\cAdobe_TSPProvider]

"iSize"=dword:00002800

For Adobe Acrobat Pro:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Adobe\Adobe Acrobat\DC\Security\cASPKI\cAdobe_TSPProvider]

"iSize"=dword:00002800