You can authorize your certificate request of a Personal ID Silver or SSL Silver certificate by clicking on the link you received by e-mail after sending your certificate request. It sometimes happens that you were not ready to receive this email because your account was not established when requesting the certificate.

You will be able to resend again this e-mail by the following steps:
a) Log-in to your account on swisssign.net and click on “Search”.
b) In case you do not have an account on swisssign.net: Just enter the license code of your request into the license field and press “Search”.

In both cases you will find your request in the result table. Near to your request you find the button “Attributes”. Please click on this button. On the next screen you will find the section “Authorization” and you will be able to click on the button “Send proof of possession email”.

You can also use a courier to send your documents for a certificate request. Please use the following address here: SwissSign Group AG, Kundendienst, Sägereistrasse 25, CH-8152 Glattbrugg.

You have already logged into swisssign.com and www.swisssign.net and obtained a certificate from SwissSign. For the request of a certificate, the signature of the authorised people and also a copy of the ID are always required. A trade register excerpt is no longer necessary, even if this is indicated to be the case on the application form.

Unfortunately with the second request you have to obtain the signatures of the authorised people again and enclose the corresponding copies of the ID. This is necessary on account of the high security regulations. To simplify the process with multiple purchases, however, you can also be authorised by the authorised people of your organisation. You can find the corresponding proxy form in here. Please refer to the following authorisation with every order or enclose a copy:

• Authorization (PDF, 97 KB)

It is of course also possible to conclude a contract for a Managed PKI directly with us (this becomes profitable from around 20 certificates).

More information on our Managed PKI service can be found here.

For SSL Silver and Personal Silver ID certificates, an electronic validation procedure is performed via the sending of an e-mail to the desired address. This e-mail will not be received, for example, if you only set up the e-mail account after making the request.

If you have created an account at swisssign.net, please proceed as follows:

• Log in at swisssign.net.
• Search for the desired certificate request. If you do not enter any parameters in the search field and click on "Search", all of your certificates and certificate requests will be displayed.
• Click on "Attributes" next to the desired certificate request.
• A new window with the "Approval" section will be displayed.
• Here, select "Send e-mail regarding proof of ownership".
• The validation e-mail will now be sent again.

If you have not created an account at swisssign.net, please proceed as follows:

• Log into your web-shop user account at swisssign.com and go to your licenses.
• Select the desired license and click on "Activate code".
• As you have already converted the license into a certificate request, you will now receive the following error message: "A certificate has already been requested".
• Below the error message, now select the "Search for already submitted requests" link. You will be forwarded to swisssign.net.
• You will now be displayed the search window with your pending certificate request.
• Click on "Attributes" next to the desired certificate request.
• A new window with the "Approval" section will be displayed.
• Here, select "Send e-mail regarding proof of ownership".
• The validation e-mail will now be sent again.

If you have created an account at swisssign.net, please proceed as follows:

• Log in at swisssign.net.
• Search for the desired certificate request. If you do not enter any parameters in the search field and click on "Search", all of your certificates and certificate requests will be displayed.
• Select "Attributes" next to the desired certificate request.
• A new window with the "Approval" section will be displayed.
• Click on the link next to "Registration document".
• The application form will now be displayed again.

If you have not created an account at swisssign.net, please proceed as follows:

• Log into your web-shop user account at swisssign.com and go to your licenses.
• Select the desired license and click on "Activate code".
• As you have already converted the license into a certificate request, you will now receive the following error message: "A certificate has already been requested".
• Below the error message, now select the "Search for already submitted requests" link. You will be forwarded to swisssign.net.
• Select "Attributes" next to the desired certificate request.
• A new window with the "Approval" section will be displayed.
• Click on the link next to "Registration document".
• The application form will now be displayed again.

The issuance speed for SwissSign certificates depends on the certificate type and reaches from a few seconds up to 10 business days for certificates, which require an intensive manual verification of the requester, of the organization or of the domain. These deadlines are valid after reception of the registration documents by SwissSign and can be held under the exclusive condition that all documents are correct and complete.

An exception are those certificates with automated issuance, which do not require submission of documents (eg. domain-validated-only SSL). These certificates are usually issued immediately.

Issuance speed for SSL Certificates:

• SSL Silver: a few seconds or minutes
• SSL Silver Wildcard: up to 2 business days
• SSL Gold: up to 2 business days
• SSL Gold Wildcard: up to 2 business days
• SSL Gold EV (Extended Validation): 5 to 10 business days

Issuance speed for Personal Certificates:

• Personal Silver ID: up to 2 business days
• Personal Gold ID: up to 2 business days
• Organization Gold ID: up to 2 business days

Issuance speed for Organization Certificates:

• PostCertificate for Organizations: 5 to 10 business days (except hardware delivery outside Switzerland)
• SwissSign Certificate for Organizations: 5 to 10 business days

These deadlines are standard values and may be subject to extraordinary exceptions (eg. important workload of the registration authority).

On account of regulations in Switzerland, SwissSign is unfortunately not permitted to issue certificates for the following countries:

• Algeria
• Belarus
• Central African Republic
• Cuba
• Democratic People’s Republic of Korea
• Democratic Republic of the Congo
• Ecuador
• Eritrea
• Guinea
• Guinea-Bissau
• Iraq
• Islamic Republic of Iran
• Ivory Coast
• Lebanon
• Liberia
• Libya
• Myanmar (Burma)
• Somalia
• Sudan
• Syria
• Yemen
• Zimbabwe

The issue of certificates is prevented here where possible. Certificate requests or the issue of certificates for these countries can also be immediately withdrawn in retrospect.

Before an SSL certificate can be issued, a Certificate Signing Request (CSR) must be generated. This is either automatically generated in the webshop www.swisssign.com* or, if the Certificate Signing Request was already generated via another tool, it can be transferred in the so-called PKCS#10 format during the order process. In this case the CA certifies only the certificate already generated elsewhere. If there is no PKCS#10 format file available, the webshop triggers the CSR process and transfers the certificate pair in the encrypted standard format PKCS#12. The file therefore also has the ending "p12".

During the generation of the CSR several fields are filled in, including the organization (O), the organization unit (OU), country (C), state (S), locality (L) and common name (CN). 

Depending on the certificate type the common name (CN) contains either the domain entry, e.g. domain.com, or with the personal certificate the e-mail address of the person, e.g. Foo@gmail.com. 

If the certificate has an organization entry, you can optionally set an OU entry. Please note that some attributes can be skipped depending on the certificate type.

*Please note that this method is no longer permitted for SSL certificates.

In the technical user account on www.swisssign.net (menu item "My Certificates", last column on the right), under the entry "Privacy" you can select between "Private" and "Public Download". This selection option concerns the public part of your certificate and determines its visibility for third parties:

• Private: with this option the certificate cannot be found. Certificate and subject are therefore not listed in the SwissSign LDAP directory. Under the menu item "Search for IDs" on swisssign.net your certificate is also not published. As standard the option "Private" is selected in each case.
• Public Download: with this option the public part of the certificate (subject and public key) is published and can be downloaded by anyone. This option makes sense in particular if you are using your certificate for encrypting messages. In this way future communication partners can obtain your public key which is needed for encryption with you.

For server certificates this setting is not particularly important because the status of the certificate can be checked by anyone at any time via CRL or OCSP anyway (links are contained in the certificate). This is irrespective of what was selected under Privacy.

Revoked certificates are listed in so called certificate revocation lists. Or they will be published by the online service OCSP which validates online current validity of a certificate. Certificate revocation lists can be downloaded here:

Certificate revocation list downloads (CRL) 

• SSL Gold EV, SSL Gold EV Multidomain
• SSL Gold, SSL Gold Multidomain, SSL Gold Wildcard, CodeSigning
• Personal Gold ID with/without Org Entry
• Personal Silver ID
• Organisation certificate

Each SwissSign certificate is signed by a SwissSign intermediate certificate. The SwissSign intermediate certificate is again signed by a SwissSign root certificate. In order to have a trustful certificate it is necessary to install the complete certificate chain e.g. on a web server. All operation systems and browsers have included the SwissSign root certificate but in some special cases it might be necessary to install the root certificate. Either it is possible to download the end certificate including the complete certificate chain on swisssign.net or the SwissSign root certificate will be installed later. 

Root certificate downloads

• SSL Silver, SSL Silver Wildcard, Personal Silver ID: Silver_G2.pem
• SSL Silver, SSL Silver Wildcard, Personal Silver ID: Silver_G2.der
• SSL EV Gold, SSL EV Gold Wildcard, SSL Gold, SSL Gold Multidomain, SSL Gold Wildcard, Personal ID Gold, CodeSigning: Gold_G2.pem
• SSL EV Gold, SSL EV Gold Wildcard, SSL Gold, SSL Gold Multidomain, SSL Gold Wildcard, Personal ID Gold, CodeSigning: Gold_G2.der
• Organisation certificate: Platinum_G2.pem
• Organisation certificate: Platinum_G2.der

Each SwissSign certificate is signed by a SwissSign intermediate certificate. The SwissSign intermediate certificate is again signed by a SwissSign root certificate. In order to have a trustful certificate it is necessary to install the complete certificate chain e.g. on a web server. All operation systems and browsers have included the SwissSign root certificate but the SwissSign intermediate certificate must be installed. Either it is possible to download the end certificate including the complete certificate chain on swisssign.net or the SwissSign intermediate certificate will be installed later.

Intermediate certificates downloads

• SSL Silver, SSL Silver Wildcard: Server_Silver_G22_2014.pem
• SSL Silver, SSL Silver Wildcard: Server_Silver_G22_2014.der
• Personal ID Silver: Personal_Silver_G22_2014.pem
• Personal ID Silver: Personal_Silver_G22_2014.der
• SSL Gold EV, SSL Gold EV Multi-Domain: EV_Gold_G22_2014.pem
• SSL Gold EV, SSL Gold EV Multi-Domain: EV_Gold_G22_2014.der
• Personal Gold ID with/without Org Entry: Personal_Gold_G22_2014.pem
• Personal Gold ID with/withour Org Entry: Personal_Gold_G22_2014.der
• Organisation certificate HSM: Personal_Platinum_G22_2014.pem
• Organisation certificate HSM: Personal_Platinum_G22_2014.der
• SSL Gold, SSL Gold Wildcard, SSL Gold Multi-Domain, CodeSigning: Server_Gold_G22_2014.pem
• SSL Gold, SSL Gold Wildcard, SSL Gold Multi-Domain, CodeSigning: Server_Gold_G22_2014.der

My operation system or my application shows an error using the SwissSign certificate or I do not know how to install the certificate in the right way.

SwissSign collects all known problems and solution in its comprehensive FAQ or gives some helpful information in its documentation. Unfortunately we cannot supply direct support. The core competence of SwissSign is the issuance of normed and trustful certificates. Due to the fact that SwissSign does not develop any applications SwissSign intentionally does not include this in its support.

But probably one of our partners can help you: SwissSign partners

After purchasing your certificates in the SwissSign webshop please proceed as follows in order to receive these:

• Log into your customer account at www.swisssign.com.
• In the user menu on the left select ″My Licenses″ and start the activation of the desired certificate by clicking on the key icon at the right end of the line.
• You will now be taken to the technical request process for your certificate. Follow the instructions in the request process here.
• As soon as your request has been checked and accepted, you will receive an e-mail with the link to download your certificate.

Instruction How do I request a certificate on swisssign.net? (PDF, 770 KB)

• Log into your web-shop user account at swisssign.com and go to your certificate vouchers.
• Select the desired certificate voucher and click on "Send activation link" in order to forward the certificate voucher to another person. An e-mail for the recipient of the certificate voucher will be prepared interactively with your entries and can then be sent.
• Shortly afterwards, the recipient will receive an e-mail containing the personal message and a link with which he or she can immediately issue the certificate at swisssign.net.

SwissSign allows the generation of your own key pair (private and public keys) with all offers. These must have a minimum length of 2048 bits.The keys generated by SwissSign also have a length of 2048 bits.

Basically the end customer or partner has no entitlement to reimbursement or credit according to the general terms and conditions. In all cases it is therefore always a concession on the part of SwissSign.

However we have seen that customers are very satisfied with their SwissSign certificates and currently act according to the following goodwill regulations: within 30 days of issue, every customer has the choice of a refund or a 100% voucher at the amount of the purchased and revoked (withdrawn) certificate.

After 30 days the customer receives a voucher for the remaining period of validity of the certificate in question in the event of revocation.

Of course, this does not affect the warranty obligation of SwissSign regarding advice and the issuing of certificates.

The root certificates of SwissSign are installed in most commonly used browsers. Update your browser to the latest version and install the latest root certificates from the Windows Update page. Dissemination of the SwissSign certificates

It is also possible that your web server does not send the complete certificate chain to clients. This problem can be solved by using the SSLCertificateChainFile function in the Apache configuration.

With SwissSign SSL certificates you get unlimited server licenses. Unlike most other SSL certificates you can install your SwissSign SSL certificate on as many physical servers as you want!

With an SSL Silver certificate, SwissSign checks the domain entered in the certificate request. Checking this is called “proof of possession”. In the certificate request process the applicant can choose who receives the e-mail on domain membership. The following selection can be made via radio button: 

• admin@indicateddomain
• administrator@indicateddomain
• hostmaster@indicateddomain
• postmaster@indicateddomain
• webmaster@indicateddomain

The “proof of possession” e-mail is sent to the e-mail address selected here. When the link contained in this e-mail is clicked on, the certificate is issued.

You receive e-mails like the following:
 

Dear operator,

The automatic CRL issuance for CA 'Silver Personal G3' failed. Please use the following link to do it manually: https://swisssign.net/cgi-bin/auth/ca?_crl=do&;selected=Silver Personal G3

Regards,

Your SwissSign Team

Please ignore this, we are examining the error and will rectify it at once.

Intermediate certificates help complete a ″Chain of Trust″ from your purchased e-mail client certificate to the trustful SwissSign root certificate.

As far as SwissSign generated your private and public key pair the client certificate and intermediate certificate are already bundled in the ′p12′ file you downloaded.

If you did a registration on swisssign.net where you provided a CSR you may need to download the format with the complete chain of trust including the issuing certificate. We offer different formats in the download area. Please pay attention to download the format with the complete chain which is clearly indicated (′p7c′, ′pem′).

Very often our customers need certificates for authentification (login) on a website.

For such a TLS-WWW client authentication you need our Personal Gold ID or Employee Gold ID certificate which can be also used for email encryption and email signature. Silver certificates do not support the usage for authentification.

Personal certificates

With a small trick you can make your visitor establish a secure connection with your website: here you need to adjust the .htaccess file so that all non-secure http entries are redirected to https entries. The change is as follows:

RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$ 
RewriteRule (.*) https://%{HTTP_HOST}/$1 [R=301,L] 

With the first line the rewrite engine is activated. The second line contains the requirement that whenever it is not the ″secure″ https port 443, the request (third line) is redirected via a permanent redirect 301 to the https page.

The endings of the file names indicate the file types. On www.swisssign.net the following file types can be downloaded with different contents:

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

*This method is not applicable for SSL certificates.

(IMAGE: swisssign_faq_ZertifikateMitPrivatemSchlüssel)

.p12 or PKCS#12 format: This format contains a public certificate and a private key (password protected). It is used for installation in mail programs, operating systems and web servers.

With web servers the entire certificate chain also has to be installed. The CA which issues the certificate typically trusts a CA at a higher level, which, in turn, trusts the root certificate of SwissSign, for example. Only the certificate of the root CA of SwissSign is recognized with all browsers. Therefore please download the certificates of the intermediate CAs on the following page and also install these.

This concerns only people who install a web server and not end users who encounter a certificate from SwissSign with their browser or mail program. This is recognized correctly by the browser or mail program. 

Certificates without a private key

(IMAGE: swisssign_faq_ZertifikateOhnePrivatenSchlüssel)

• .cer: DER or BASE64 encoded
• .crt: DER or BASE64 encoded
• .pem: Base64 encoded certificate, surrounded 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 complete certificate chain (e.g. for Apache and similar platforms) 

The Registration Authority (RA), a service of SwissSign, checks the identity and, if necessary, the attributes of every applicant for a certificate before the CA generates the certificate of the applicant or allocates the data for activating the use of the signature key.

Pfx format is the same format as p12. Please download the p12 file and rename it.

You requested SwissSign to generate a private and public key during the certificate request. The private key was immediately encrypted via the transfer password. The password must be entered e.g. during every installation of the certificate. As far as this password is not known anymore SwissSign is not capable to help you. Secured by internal processes and algorithms the password cannot be decrypted and also a reset is not possible. Unfortunately you have to order a new certificate and to keep your password safe.

• First of all in the Synology system a CSR (Certificate Signing Request) needs to be created. This means that the key pair has also then been created on the Synology server.
• After the issuance, the certificate should be downloaded in the format ".pem" from www.swisssign.net. All other formats can cause error messages, e.g. "File encoding must be saved as UTF-8".
• The intermediate certificate (type G22) should be downloaded from the download page.
• Now on the Synology server the files "private key" (locally generated) and also the certificate in pem format and the intermediate certificate in perm format can be loaded.

• Linux installation software for the organization certificate on a smart card
• Mac installation software for the organization certificate on a smart card
• Windows installation software for the organization certificate on a smart card

Umlauts, Accents are not correctly displayed in Excel after a CSV export of search results on the platform swisssign.net.

Excel does not open the file UTF-8 encoded. By this all umlauts are not displayed correctly. In order to avoid this problem we propose the following:

1. Please save the exported CSV file locally in CSV format
2. Open in Excel the menu item “data” and select “from text”
3. Select the saved CSV file mentioned in 1.
4. Enter in the popup window of the import wizard the file origin “UTF-8”

Now you will see the results correctly in Excel.

If you received your SHA-1-based SSL and Code Signing certificate from a reseller, the reseller will receive a corresponding voucher code for your certificate. Speak to the reseller about this.

Here you find the instructions on signing PDF documents.

No, revoked certificates or certificates declared invalid also remain on the Certificate Revocation List (CRL) after the expiry date indicated in the certificate. The reason is that for the validation of the signature it is important to know when a certificate was revoked.

SwissSign offers a ldap server access with directory.swisssign.net The search base is: o=SwissSign,c=CH.

It is important that the certificate are publicly visible.

There are different tools for reformatting. One of the best known ones is www.openssl.org:

• Convert a certificate from PEM to DER format: openssl x509 -in cert.pem -inform PEM -out cert.der -outform DER
• Convert a certificate from DER to PEM format: openssl x509 -in cert.der -inform DER -out cert.pem -outform PEM

As a customer of a SwissSign Managed PKI solution, contact the RA (registration authority) at your company. If you have received your certificates via the swisssign.com web shop or one of our web-shop partners, send us a digitally signed e-mail at the following address:  helpdesk@swisssign.com.

The e-mail is encrypted with the help of the recipient certificate. This means it is necessary for the sender to receive the certificate of the recipient. This can be done manually or also by a corresponding secure mail gateway collecting the certificates from incoming e-mails.

The organization certificate smart card is based on SuisseID. The corresponding software and driver can be found here:

• Technical documentation for Windows
• Technical documentation for Mac (Linux)

Under Unix after installation you will find the PKCS#11 module under “/usr/local/lib/libcvP11.so”. If signing is done under Unix with PKCS#11, ACS ACR38T USB Reader and the Siemens ATOS smart card (SuisseID component) (key length 2048 bits), there is a performance of one signature per second.

The main web browsers all naturally support OCSP stapling:

• Apache/nginx
• Microsoft IIS

You will also find further information here.

Here we absolutely recommend upgrading the system or replacing it so that SHA-2 certificates can also be used. The new provisions of the CA Browser Forum stipulate that Certification Authorities may only issue short-term certificates based on SHA-1. For major customers with several certificates, SwissSign offers this service to issue certificates with a period of validity of several months for a transition period. This is done on a project basis, i.e. for this we need a precise list of the certificate types and the number and can then make an offer.

Basically we also offer to withdraw and reimburse the SHA-2 certificate if this cannot be used.

If you are using SHA-2 SSL certificates, your customers with older operating systems or browsers can maybe no longer open your websites: this concerns, for example, all customers who are still using Windows XP systems with Service Pack 2 and have not updated to Service Pack 3.

The new Windows systems support all SHA-2. Unfortunately we are only a supplier of certificates which will be issued in a standardized form. If these certificates are accepted by all operation systems, applications and different versions is difficult to say. There are too many systems and versions on the market. Please apologize that we cannot support you in detail. Please contact your supplier of your operation system or application for more details. We would just like to communicate the information we got from operation system and application vendors (without any warranty):

Java-based web servers support SHA-2 as long as Java SDK 1.4.2 or higher is used.

Apache-based servers should be based on an Apache version 2.x or higher. For the key generation at least Open SSL 1.1.x should be used.

Older specific hardware, e.g. point of sale systems, could also have problems. Here you need to ask the manufacturer in good time whether these systems can be updated to a current software version.

In detail the operating system and software producers have given the following recommendations about which system versions support SHA-2 (reproduced subject to correction):

Operating systems

• Windows from version XP SP3
• Windows Phone from version 7
• Windows Server from version 2003 SP2 including hotfixes
• Android from version 2.3
• Apple OS X from version 10.5
• Apple iOS from version 3.0
• Blackberry from version 5.0

Server systems

• Apache from version 2.0.63 with OpenSSL 0.9.80; higher version recommended because of Heartbleed.
• JAVA from version 1.4.2
• Mozilla NSS from version 3.8
• Oracle Weblogic from version 10.3.1
• IBM Domino Server: support starting with version 9.0.1 FP2
• Citrix: see detailed list
• IBM http Server from version 8.5 

Browsers

• Internet Explorer from version 6, with Windows operating system from version XP SP3
• Mozilla from version 1.4
• Firefox from version 1.5
• Chrome from version 26
• Netscape from version 7.1
• Opera from version 9.0
• Safari from version 3

 
E-mail applications

• Outlook 2003/2007 with Windows XP SP3: cannot verify and send a SHA-2 signed e-mail.
• Outlook 2007 and higher: Supports SHA-2.
• Mozilla Thunderbird 24 with Windows XP SP3: Can verify SHA-2 signed e-mails. With SHA-1 there were generally problems with sending signed e-mails.
• IBM Notes 9, IBM Notes basically also supports SHA-2 but has problems with the verification of signed e-mails.

There are basically two possible reasons for this:

• When establishing SSL encryption or also in e-mail systems the installation of an intermediate certificate was forgotten.
• The customers run a so-called «SSL Inspection» in their proxy. This is a function which breaks the encrypted connection and checks the communication for unpermitted contents or even malware during the download process. SSL Inspection generally works with non-trusted, own certificates. This means not only pages with SwissSign certificates but also other pages are affected. The problem is generally solved by configuring the affected page from the proxy.

Chrome version 42 indicates all SSL connections which are still based on the SHA-1 algorithm as unsafe, either with a red cross in the browser or with an exclamation mark. The connection is not yet blocked.

Please replace your SSL certificate with a SHA-2 certificate. SwissSign offered its customers an exchange programme between October 2014 and the end of November 2015. 

Only SSL EV certificates issued from 1 January 2015 are affected. With these certificates the green address line of the browser (green bar) is missing with the Google Chrome browser from version 41. Only the https is shown in green with a green key. In the information on the certificate, the identity of the organisation which is running the website is still confirmed. But it is also indicated that there is no public entry.

No, there are no master certificates. The only possibility is to issue a certificate for a “neutral e-mail address”, e.g. info@xxx.

Please contact our support team.

Often these problems are not based on missing or defective root certificates in the operating systems or browsers but rather when establishing SSL encryption or also in e-mail systems the installation of an intermediate certificate was forgotten.

Certificates are arranged hierarchically: The certificate itself trusts an intermediate certificate, if necessary this trusts another intermediate certificate etc. Ultimately the intermediate certificates also trust the root certificates which are listed in the browsers and operating systems. Since the browsers and operating systems contain only the root certificates, the chain of trust is broken without intermediate certificates.

In the Windows environment these problems occur more rarely because Microsoft Windows or the Windows browsers try to store intermediate certificates on a temporary basis as soon as a page, for example, has been accessed with the correct installation of a SwissSign certificate. This temporary storage is then automatically used if the intermediate certificate has not been installed correctly and the user is not at all aware of the «error». With Linux, however, the missing configuration becomes evident immediately.

This can be corrected by downloading the entire certificate chain and installing the certificate chain including intermediate certificates.

• To do this, please go to the link you received during the certificate issue process in order to download the certificates. Alternatively you can also look for your certificate on swisssign.net and then press the «Download» button.
• In the available download formats select the file with the ending .p7c or .pem (entire certificate chain). All other downloads – including the .p12 file – contain no intermediate certificates. 

Yes, this is possible. On page 7 of the instruction How do I request a certificate on www.swisssign.net? (PDF) you will find a sample of a confirmation mail with the link for downloading the certificate.

The CP/CPS foresees a daily (24 hour) update of the Certifcate Revocation File (CRL). In daily operation SwissSign will update the CRL more frequently on a hourly base. If you look into the CRL file you will see that it is valid for 10 days, it is shown in the field "Next update". This is necessary since the CP/CPS foresees in the force majeur case that in the worst case the CRL file must be updated within 10 days if some system had a breakdown.

You need the corresponding private key in order to decrypt the data. You must make sure that your old encryption certificate is still imported in your browser. This is the only way to decrypt data that was encrypted using your old certificate. If the certificate no longer exists in your browser, log into your SwissSign profile and download the certificate again. To do this, you will need the 16-character password you entered when you created the certificate.

Your computer is not recognizing the issuer as a trusted source. This can be rectified by describing the issuer as trusted. Usually the producers of these programs undertake this task via their root store programs.

By entering the issuer SwissSign as a trusted root or answering the question “Do you want to trust the issuer?” with yes. If you are using a company PC, please contact your IT support team.

Adobe Acrobat (PDF) does not address the trustworthy certificates in the Windows Certificate Manager by default and therefore cannot check the authenticity of the certificates used. To change this, please do the following in Adobe Acrobat:

Under Edit – Preferences – Security – Advanced Settings, open the Windows Integration tab and activate the three check boxes. The next time a check is made, a valid certificate sign should be shown.

Revocation is the process that makes a certificate invalid. Revoked certificates are listed in the Certificate Revocation List (CRL), and the CRL is published by the CA as per the corresponding CP/CPS (Certificate Policies CP/Certificate Practice Statements).

When an encryption certificate is revoked, it is extremely important that you store the corresponding private key. You will still need this key to decrypt data that was encrypted using the old (revoked) certificate. When a signing certificate is revoked, you can safely delete the private key, because you can no longer use it to create valid signatures.

Technically the certificate has to be issued again when the content is changed, and this involves costs. With the current price structure the charge is per valid subject if the number of issued certificates remains within a fair framework.

Reasons for revoking a certificate or declaring it invalid: 

• The user has forgotten their password for their private key. 
• The key material has been corrupted. 
• The information in the certificate is no longer up-to-date (e.g. e-mail or leaving the organization).

You can revoke SwissSign certificates in three ways: 

1. Online revocation: possible when you have requested the certificate via a technical user account on www.swisssign.net.
2. Online revocation: also possible when you still have your private key or the revocation code. Please open the swisssign.net page and enter in the „Licence“ field your license number for the certificate you received at the time of purchase. You do not need to login. The certificate is displayed. You can now revoke the certificate with the revocation code from the approval mail by click on the button „Revoke“.
3. Offline revocation: for this you have the offline revocation form (PDF, 57 KB) available.

Yes, you will receive an e-mail 30 days and 10 days bevore expiration of your SwissSign certificate.

Both.

Since 1 April 2015, CAs have no longer been able to issue 5-year SSL certificates. If, after this period, the customer uses certificate licences which were purchased before, we are obliged to withdraw these licences. Affected customers can have their certificate reimbursed by us or receive a 3-year certificate and a voucher to purchase another certificate. Please contact our support team here.

With suspension the validity of a certificate is temporarily suspended.

SwissSign does not offer temporary blocking of certificates. The reason is that blocked certificates go on a revocation list (CRL) and have to be removed again later. So afterwards the timeframe in which a certificate was suspended cannot be tracked. With qualified certificates temporary blocking is also prohibited by law.

You need the corresponding private key in order to decrypt the data. You must make sure that your old encryption certificate is still imported in your browser. This is the only way to decrypt data that was encrypted using your old certificate.

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

An extension of the validity is unfortunately not possible. You have to buy a new certificate license and to request for a new certificate. In case you have to manage mutliple certificates probably a managed PKI solution will be helpful. With Managed PKI you have only to do the validation process once.

In case of a gold certificate you have to fill in again the completely signed form. Please do not forget the signature of your domain owner and enclose a copy of your ID or passport of all persons who signed your registration form. A trade registry report is not necessary anymore.

When issuing a certificate it is given a fixed period of validity. This means you have to request a new certificate upon expiry. Here we have to check if the desired certificate content is still valid. To prevent certificates being exchanged annually, we recommend that you purchase certificates with longer validity periods. 

At SwissSign an extremely secure process is used for generation. The basis is a random generator which is provided with many random events which cannot occur again. Here random, current status information is used by processes, different time stamps, process numbers, etc. This very complex random process is carried out once for every key and is therefore unique.

Using certificates guarantees you security, privacy and trust. They are used in various applications: secure mail, e-business, e-government, e-health and so on.

Find out more on the partner solutions page

The public key procedure is an asymmetrical, cryptographic procedure in which a pair of keys is used. This cryptographic pair of keys consists of a public and a private key. Data encrypted with one of these keys can only be decrypted with the other key. This cryptographic method can now be used both for encryption and also for technical signatures.

In the case of encryption, the data are encrypted for the recipient with the public key (key in the certificate) and can now be decrypted only with the corresponding private key.

In the case of the technical signature the data are encrypted for the recipient with the private key of the sender and can then be checked by the recipient with the help of the public key.

The public key is publicly accessible via the certificate. This key is used for encrypting data or confirming the digital signature of the signatory (identification). Data encrypted with the public key can be decrypted only with the corresponding private key.

The private key is known only to/may be accessed only by the certificate holder. It is used for decrypting data and for creating a digital signature.

The certificate contains an entry “Key Usage”. This field defines the usage for the certificate. Possible key usage entries include: digital signature, non-repudiation, key agreement, key Encryption and/or data encryption.

The term “dual keying” is often used in the context of secure e-mail.

If you have a well-developed application then you can sign and encrypt e-mails. Simply import a SwissSign certificate into your e-mail application and off you go. But please be careful. When you use a certificate for encryption and signing there is a risk you might lose important data. If you lose the pass phrase for the certificate, or even the certificate itself, then you will not be able to read your own encrypted data. For businesses and for private users too, this is not acceptable.

Dual keying uses two key pairs (two certificates) to avoid this risk:

• One pair for encrypting e-mails. Always make a backup of the private key for this certificate. The best place for this backup is the SwissSign online database. If you lose the encryption certificate, simply log into your SwissSign profile and download the certificate again. You could also use a disk or CD.
• One pair for signing e-mails. Never make a backup of the private key for this certificate. If you lose your signing key then this is not so much of a problem, simply create a new one.

Digital signatures provide the basis for identifying a signatory of an electronic document and protecting the integrity of the data contained in this. With the digital signature it can be reliably shown from whom the digital data – for example an e-mail or a document – comes (authenticity), and a subsequent change of the document is recognised immediately (integrity).

You can use a private key for digitally signing documents (e.g. e-mails, PDFs). If your certificate is valid at the time the signature is made, a valid digital signature is generated. This digital signature can be verified by anyone who is in possession of your public key. This proves that you signed the document.

A root certificate is a certificate signed by a CA (Certification Authority). To use a root certificate you must first trust the corresponding CA. Using a root certificate infers that the user instance recognizes and accepts all certificates issued by the relevant CA.

For a detailed description of CA usage, organization, functions, methods and processes, see the SwissSign Certificate Policy CP/Certification Practice Statement (CPS): Repository

Trust is the basic principle in every security model. This is also the case with the public key infrastructure (PKI). To be able to work with certificates at all, the CA which issued the certificate has to be trusted.

PKIs are always organized hierarchically. The top level of the hierarchy (root) has to be stored explicitly as trusted so that the content of the corresponding root certificate is trusted.

The SwissSign root certificates are recognized as trusted, i.e. they are stored in places including the following root trust stores: Microsoft, Mozilla (NSS) and Apple OS X (dissemination of SwissSign root certificates). The SwissSign certificates are therefore displayed as trusted to the end user of these applications. So as soon as the root certificate of a PKI is stored as trusted, every subcertificate of this hierarchical structure can be safely checked.

Trusting a CA like SwissSign also means trusting the various processes belonging to the PKI, such as user registration or certificate validation (CRL, OCSP). The certificate policy and certification practice statements (CP/CPS) bring transparency to the processes here and help reinforce trust. You determine your trust in the SwissSign CA by reading the corresponding CP/CPS. SwissSign is also a qualified Certification Service Provider according to Swiss law which meets the requirements of the Swiss Federal Act on Electronic Signatures (ZertES). ZertES in turn corresponds to the strictest international standards in this area.

Finally also import the corresponding SwissSign root certificates into your programs to establish the relationship of trust.

A Certificate Authority (CA) is a provider of certification services or a certification body – a “trusted third party”. Sometimes talk is also of a Certification Service Provider (CSP).

SwissSign is a CA – an authority which, within an electronic environment, confirms data of people, organisations or machines and issues digital certificates for this purpose.

A Registration Authority (RA) is a service of SwissSign which consists in checking the identity and, if necessary, the attributes of every applicant of a certificate before the CA generates the corresponding certificate or allocates the data for activating the use of the signature key.

CAOs or RAOs are “operators” (people) with specific functions and obligations for the CA or RA.

A public key infrastructure (PKI) is an infrastructure or environment where various applications and functions work using cryptographic keys (public key and private key) and certificates. These applications range from access control and secure e-mail through to various types of digitally-signed information relating to the CA or RA.

The Certificate Policy (CP) is a document of the Certification Service Provider (CSP) that describes the various actors of a Public Key Infrastructure (PKI) and their roles and obligations. It comprises all rules which stipulate the applicability of a certificate for a specific group of people and/or a class of specific applications with shared security requirements. Third parties use it to analyse trustworthiness.

When in use with X.509 certificates (all SwissSign certificates), a specific field can be set to include a link to the associated certificate policy. Thus, during an exchange, any relying party has an access to the assurance level associated with the certificate, and can make a decision concerning the level of trust to put in the certificate.

CPS means Certificate Practice Statement, i.e. statements about the rules and guidelines which are effectively implemented by SwissSign for issuing certificates. The CPS defines the equipment, policies and procedures used by providers of certification services in accordance with the certification policy selected by them. The CPSs correspond with international standards based on RFC3647.

CP and CPS form the legal basis for the relationship between the certificate holders and SwissSign.

SwissSign CP/CPS (Repository)

Microsoft announced in November 2013 that from January 2016 it will no longer accept Code Signing certificates and SSL certificates with SHA-1 as trusted.

SHA-2 consists of several cryptographic hash algorithms developed by the National Institute of Standards and Technology (NIST) which are going to replace the weaker SHA-1 hash algorithm.

Google also announced in September 2014 that probably from January 2015, in all versions of the Google Chrome browser, websites which are protected with certificates which are still valid after 1 January 2016 and are based on the SHA-1 algorithm will be displayed as unsafe.

In the virtual world the term trust has a new dimension. Users must be able to clearly identify their communication partner.

A digital or electronic certificate is an electronic confirmation which links a signature validation key with the name of a person, organization or a server. Or in other words: a certificate is an unchangeable “electronic identity card” which the user can use for identification and/or encryption on the internet. 

Identification: certificates are used

• in order to identify the sender of information.
• in order to identify the server with which a user connects.
• in order to identify the user that connects with a server.

Encryption: digital certificates contain the public key of the certificate holder. This can be used by the user’s counterpart in order to encrypt an e-mail or a document sent via the internet.

Certificates also play an important role in secure web transactions such as https (SSL certificates).

There are various types of digital certificates. The minimum set contains the following: 

• The public key of the certificate holder (person, computer/machine or organization)
• Information on the certificate holder
• Information on the issuer of the certificate, i.e. on the CA or the organization that delivered the certificate.
• Digital signature of this certificate by the issuer
• Delivery and expiry date of the certificate
• Serial number of the certificate
• Certificates from SwissSign also contain information on the CP/CPS.

At SwissSign an extremely secure process is used for generation. The basis is a random generator which is provided with many random events which cannot occur again. Here random, current status information is used by processes, different time stamps, process numbers, etc. This very complex random process is carried out once for every key and is therefore unique.

Producers of browsers, operating systems, mail clients and other pieces of software that evaluate certificates have to maintain a program by managing the CSPs that they recommend to their customers as trusted CSPs (root store program).

A lot of work is required to maintain your own root store program. It comprises maintaining the requirements documents and the incorporated CSPs. Maintaining the minimum requirements documents is therefore the responsibility of the CA Browser Forum. In this body the root store program maintainers (software producers) and the CSPs are represented and compile and maintain the requirements documents together.

Today more and more root store programs are based on the ″baseline requirements″ of the CA Browser Forum. www.cabforum.org

The certificate contains the public key. If, for example, Alice wants to send you a confidential e-mail and use the public key procedure here, she needs your public key. One of the tasks of a CA is to also make the public keys publicly accessible.

SwissSign offers you three privacy levels. In the technical user account on www.swisssign.net (search the certificate and press „attributes“), under the entry «Privacy» you can select between “Private”, “Public Lookup” and “Public Download”. If you have not created an account on swisssign.net, you can directly search your certificate with the license code purchased at the purchase and make the selection via "Attributes". This selection option concerns the public part of your certificate. You yourself therefore determine the visibility of your certificates for third parties.

Here you should read the document Information on the legal significance of SwissSign certificates (PDF, 271 KB).

Every digital certificate has the following life cycle: 

• Certificate request: a user requests a certificate. 
• Request check: the Registration Authority (RA) checks the identity of the user/applicant. 
• Generation/issue of the certificates: the Certificate Authority (CA) issues the certificate. This certificate contains information on the holder, the issuer, the permitted use and its lifespan (valid from and valid until).
• Suspension: the certificate is temporarily blocked. This is not practiced at SwissSign.
• Revocation/invalidity: the certificate is revoked or declared invalid before expiry.
• End of certificate validity: the certificate has expired.
• Certificate renewal: renewal of the certificate.

The Time Stamping Authority (TSA) is the service of a CA which gives certification provided with the date, time and a signature of the CA and according to which certain digital data existed at a specific time. The SwissSign Time Stamping Authority corresponds with Swiss legislation (ZertES).

Like in the physical world, it is also dangerous in the digital world if someone loses a key or the key is no longer valid, e.g. because of the departure of an employee. Keys/certificates are therefore repeatedly registered which have to be blocked in order to prevent damage. SwissSign publishes – like every CA – these keys/certificates in so-called "Certificate Revocation Lists" (CRLs).

The CRL contains all serial numbers of the certificates which were declared invalid before the expiry of their certificate lifespan. In the certificate status check the list is loaded from a public URL and the serial number of the certificate which needs to be checked is looked for in this list: if it is present, the certificate is blocked, otherwise it is valid.

Revoked certificates or certificates declared invalid also remain on the CRL after the expiry date indicated in the certificate. The reason is that for the validation of the signature it is important to know when a certificate was revoked.

As a rule CRLs are updated at regular intervals. As with the certificates, with the CRLs the lifespan is also specified in the CRL itself. This lifespan is much longer than would be assumed from the issue frequency (at least twice a day). This means «fault majeur» is also covered. CRLs can be stored locally on an intermediate basis and enable a certificate status to be queried offline. Here the connection between certificate holder and the relying party is not disclosed to the CSP. There is a relatively high level of inaccuracy when querying the status of a certificate, however.

One alternative is the validation service OCSP (Online Certificate Status Protocol) which works online. In real time this gives information on the validity of a certificate. For OCSP use the high performance of the CA is important. The SwissSign CA ensures this high performance and also uses only its own software developed in Switzerland for OCSP. Online status checks are usually used where it is important to check the precise time of the certificate, e.g. with financial transfers. 

• The message has not been changed since it was sent.
• Depending on the CP/CPS connected with the signing certificate, you can trust that the sender is who the sender claims to be.

Google Chrome is based on the model of "Certificate Transparency" (CT). Based on the CT security it will be easier to detect and identify faults made by Certificate Authorities and to eliminate insecure web sites. This process pushed by Google Chrome is an important support of trustful internet communication.

Basic idea: by use of secure logging all certificates for secure internet communication should be registered. At least 3 different log servers should be used. Fraudulent certificates, manipulations, illegal registrations, not-allowed additions should be detected by the internet community. A certificate could be easily revoked and would be excluded from any communication by browser.

SwissSign EV certificates are registered in at least 3 certificate transparency logs. Every user of a EV certificate can benefit from the logging and will see a green bar in the Google Chrome browser if OCSP stapling is enabled. SwissSign registers the certificate also at a Pan-European certificate transparency log together with other European certificate authorities.

In the corresponding CP/CPS of the issuer you can see the quality with which the certificate holder (sender) was identified by the issuer. This means the authenticity of the sender is indicated by a valid and trusted signature. Healthy suspicion is advisable with unknown senders, however, especially when the issuer of the signature is also unknown.

Basic information: e-mails are encrypted with the public key of the recipient and decrypted with the private key of the recipient. Signing is done with the certificate.

• Certificates or the password for the private key can be lost. The e-mails encrypted with this certificate can no longer be read by anyone.
• Certificates are renewed but it is forgotten to also install the expired old certificate. All old stored e-mails can no longer be read.
• An employee leaves the company or is absent for a considerable time. His e-mails can no longer be read by anyone else.
• A virus or Trojan is sent with an encrypted e-mail. No antivirus program can search through an encrypted e-mail, the virus or Trojan can infiltrate with impunity. This means that encryption can even mean a security risk in this case.
• The customers themselves are always responsible for the installation of the certificates on their mail client. Not all users have the necessary experience for installing these certificates.

The term “qualified certificate” was coined in Europe during an EU-wide effort to promote a consistent standard for PKI systems. Although there is no formal definition, a qualified certificate usually describes a type of certificate issued according to legal guidelines for national legislature. At this time Switzerland is subject to its own digital signature law: the Swiss Electronic Signature Act or ZertES, SR 943.03. In the EU the standard is ETSI TS 101 456, and in the USA and Canada ANSI X9.79.

http + Secure Socket Layer SSL = https

https is the standard for the encrypted transfer of data between browser and web server – for secure web transactions. It is based on X.509 certificates. An asymmetric encryption procedure is used here. This requires a lot of mathematical work and causes high processor utilization. Therefore the transferred keys cannot be intercepted by an attacker.

This is how it works (establishment of the HTTPS connection): the web server sends the browser its digital certificate signed by a CA (web server certificate). On the one hand this contains the public key of the web server, and on the other hand it identifies the server. The browser checks this is authentic with the help of the installed CA certificate – the browser trusts correctly signed web server certificates. The browser now generates a secret symmetric key which is used only for this SSL session, encrypts it with the public key of the web server and sends this to the web server. Other data can now be encrypted with this session key. Symmetric data encryption can now begin with the secret session key now available on both sides. This is clearly easier and causes only low processor utilization.

Role of the CA: this guarantees the unaltered transfer of the public keys and the authenticity of the web server. The certificate of the CA is installed in all browsers and appears there as a «trusted root certification authority». If the certificate is not installed, the user receives an error message when opening the website. The web server also generates a key pair whose public part is transferred to the CA. The CA checks the data of the web server operator and signs the key. The thus created web server certificate guarantees the authenticity of the web server and represents a guarantee for users that they have connected with the right web server.

For Outlook Web Access (OWA) you need a SSL certificate that is installed on the OWA server. Depending on which level of trust you want, select between an individual Silver, Gold or Gold EV certificate.

The SwissSign CA trust center has to meet very high requirements so that certificates are considered sufficiently secure. A key aspect for security is the key length, which is repeatedly adapted on account of progress made in computer science and cryptology.

Since 2010 the industry standards have recommended a key length of 2048 bits for asymmetric certificate keys. Symmetric keys can then be exchanged with these asymmetric keys and contents encrypted symmetrically.

The SSL certificate with its asymmetric keys is used only for the unique and secure identification of the server, for mutual authentication and also for setting up the secure channel for exchanging symmetric keys. For performance reasons the data exchange itself is then only via the exchanged symmetric keys. All SwissSign SSL certificates allow the highest possible key length of the symmetric keys, which today are typically 256 bi

With the technologies of integrated communication and collaboration (Unified Communications & Collaboration, UCC) Microsoft offers an efficient and easy way of communication across several applications. Unified interfaces extend the compatibility between office products and allow an easy and secure electronic data exchange.

The central UCC element is Microsoft® Exchange™. Other UCC-applications are Outlook Webaccess, ActiveSync, Outlook Anywhere, Autodiscover, POP3, IMAP4, Unified Messaging, Office Communications, Office Enterprise, Office SharePoint and Office SharePoint Designer. However, simplifying the communication channels also represent an increasing challenge to the security, since data exchange between the UCC servers must be secured.

The creation and issuance of certificates is performed based on the standard RFC5280. The new standard foresees the placement of the email address in the Subject Distinguished Name as well as in the Subject Alternative Name (SAN). In special the mail applications will analyze the entry in the SAN field. The placement of the email address in the special email address attribute of the Subject Distinguished Name was only done in legacy implementations and is no longer supported by SwissSign.

ZertES is the abbreviation of the Swiss Federal Law on Certification Services for Electronic Signatures (Schweizer Bundesgesetz über Zertifizierungsdienste im Bereich der elektronischen Signatur) from 19 December 2003, ZertES SR 943.03.

Balance sheet and profit and loss account have to be archived physically and signed by hand. If they are archived electronically, the originals have to be stored.

Account books, vouchers, business correspondence and inventories (ledger such as accounts and journal, subledgers, in particular wage accounting, accounts receivable and accounts payable accounting, stock / non-invoiced services) can be archived electronically.

The necessary registration systems for the CT model, so-called "certificate logs", have been offered only by US providers (Google, DigiCert) so far. In the light of this, in July 2014 the key players from D-TRUST, SwissSign and Izenpe decided to pilot their own certificate log which aims to support the CT model via a completely independent log infrastructure.

One of the key goals of the initiative of the three trust centres is to ensure that the green address line of the browser (green bar), which informs internet users of a trusted connection, will also reflect the interests of all the providers represented in the international CA/Browser Forum in the future.

After all, if only the US CT model (Google) succeeds, there is the worry that individual certificates could lose the established quality seal of the green extended validation bar despite high security standards.

Basically it is up to you to decide which certificate is suitable for which purpose (e.g. archiving or invoicing) and corresponds with the legal requirements and your internal regulations.

Unfortunately SwissSign can only give you general information here and is not authorized to give conclusive recommendations. The legal situation is, for example, different depending on the canton and also depends on whether international law applies or whether there are internal regulations in the authority or company.

The procedure for the signature of your code depends on the underlying platform. The instructions are available from the corresponding manufacturers:

• Microsoft ″Authenticode″: You can use our certificates. With the new Windows SDK, the code can also be signed on the Windows platform. An example of a typical access path in Windows for SignTool: signtool sign /tr http://tsa.swisssign.net /a /f <P12 file> /p <Password for P12 file> myprogram.exe
• osslsigncode 1.5.1, which is also used for cross-compiling Windows on Linux, likewise supports RFC 3161 with the -ts option, see also the osssigncode website osslsigncode
• Java JAR Signer: You can use our certificates.
• Android: You can use our certificates.
• Apple iOS / OS X: Since recently, Apple has exclusively accepted its own certificates – i.e. the certificates of third-party providers such as SwissSign cannot be used for code signing.

RFC stands for ″Request for Comments″. RFCs are working documents that are generally and internationally accepted as Internet standards. The RFC system was created soon after the Internet came into existence.

More information under www.rfc-editor.org.

The development of an independent pan-European log infrastructure was completed last autumn and presented to Google for approval. Google has not yet completed the approval process. SwissSign is therefore working on entering the SSL EV certificates first of all in the two Google CT logs. As soon as the pan-European log has been approved, all SwissSign certificates will receive approvals from three CT logs: two Google CT logs plus the pan-European log. According to Google, this is the requirement from the summer so that the certificates will continue to be displayed with green bars. Until then an entry in one log also suffices.

Unfortunately the Google Chrome schedule changes regularly and the deadlines communicated initially are also not being observed: it is clear that such a system change needs time.

SwissSign registers all EV certificates in both certificate transparency logs of Google and additionally in the Pan-European certificate transparency log. Please note that you have to enable the “OCSP Stapling” feature on your web server. Starting in 2016 browsers like Chrome and Firefox will start to require “OCSP stapling” for certificate usage.

CT logs complement the SSL security system and increase its level of trust – they do not replace it.

(IMAGE: swisssign_faq_CT-Logos.png)

Link to download the intermediate certificates

Published in 2013, Certification Authority Authorization (CAA) is an Internet standard with the designation RFC 6844.

Adopting a similar structure to a large phone book, domain names are listed in a globally distributed register of names, the so-called Domain Name Service (DNS). A website with a recognisable name like www.swisssign.com is translated by this service into an Internet address such as “46.175.9.80”, meaning that it can be accessed by various Internet services (e.g. a browser). In addition to this function, the Domain Name Service also allows for the provision of additional information, such as the name and address of a website’s owner.

Thanks to the CAA standard, further information is now saved for these domains: It is recorded which certification authority is permitted to issue a certificate for the named domain. If no certification authority is recorded, any certification authority can issue a certificate. Otherwise, a certification authority cannot issue a certificate for the domain if its name is not stated here.

Why has this rule been applied?

In recent years, there has been an increasing number of “man-in-the-middle” attacks, a means of attack that is also used by secret services around the world. In order to enable them to spy on who is accessing an encrypted website, they ask an allied or compliant certification authority to issue an identical certificate for the website in question. Using this “fake” certificate, the website is then reconstructed by the attacker, with the data traffic initially being directed to the fake website by means of router manipulation. The details are then listened into and the communication is forwarded directly to the original website. In most cases, the website subjected to the attack and its visitors are none the wiser.

A CAA entry can reduce this risk by allowing for the deliberate recording of trusted certification authorities. Since September 2017, all certification authorities permitted in the browsers have been required by the CA/Browser Forum, an association of browser producers and certification authorities, to check the CAA entry prior to issuing a certificate.

CAA is a process whereby the domain owner can determine which CA is allowed to issue certificates for its domain. A so-called CAA record is entered in the DNS. From September 2017, SwissSign will check all domains before issuing certificates to determine whether you have a restriction in your CAA record. Domains that have been restricted to accept certificates from certification authorities other than SwissSign are not allowed in the certificate. The certificate application is rejected. If no restriction has been placed or the CAA record names SwissSign as CA, the certificate will be authorized.

The CAA configurator supports you in defining the exact parameters for your web site.
Here are some examples depending on the DNS technology used:

Permission for SwissSign to issue certificates

Standard BIND Zone File

For BIND ≥9.9.6, PowerDNS ≥4.0.0, NSD ≥4.0.1, Knot DNS ≥2.2.0

example.com.     IN       CAA      0 issue "swisssign.com" 

Legacy Zone File (RFC 3597 Syntax)

For BIND <9.9.6, NSD <4.0.1

example.com.     IN       TYPE257  \# 20 0005697373756573776973737369676E2E636F6D

Permission for SwissSign to issue non-wildcard certificates

Standard BIND Zone File

For BIND ≥9.9.6, PowerDNS ≥4.0.0, NSD ≥4.0.1, Knot DNS ≥2.2.0

example.com.     IN       CAA      0 issue "swisssign.com"

example.com.     IN       CAA      0 issuewild ";"

Legacy Zone File (RFC 3597 Syntax)

For BIND <9.9.6, NSD <4.0.1

example.com.     IN       TYPE257  \# 20 0005697373756573776973737369676E2E636F6D

example.com.     IN       TYPE257  \# 12 0009697373756577696C643B

Permission for SwissSign to issue only wildcard certificates

Standard BIND Zone File

For BIND ≥9.9.6, PowerDNS ≥4.0.0, NSD ≥4.0.1, Knot DNS ≥2.2.0

example.com.     IN       CAA      0 issue ";"

example.com.     IN       CAA      0 issuewild "swisssign.com" 

Legacy Zone File (RFC 3597 Syntax)

For BIND <9.9.6, NSD <4.0.1

example.com.     IN       TYPE257  \# 8 000569737375653B

example.com.     IN       TYPE257  \# 24 0009697373756577696C6473776973737369676E2E636F6D

With SwissSign SSL certificates you get unlimited server licenses. Unlike most other SSL certificates you can install your SwissSign SSL certificate on as many physical servers as you want!

Unfortunately no. Since according to www.whois.ch you are not the owner of the domain dyndns.ch or dyndns.org and DynDNS does not carry out any domain validation, it is difficult to receive confirmation of the owner that can also be checked.

In order to obtain an SSL Gold EV certificate, associations also have to indicate a register number.In Switzerland, like companies associations can apply for a business identification number (UID). This is not to be confused with the EU VAT ID (called EU-UID in German). Associations with an annual turnover of less than CHF 150,000 are exempt from VAT but receive a business identification number on request. This business identification number has to be entered in the certificate as a register number. German associations are entered in the register of associations as registered associations and can use this number.

The SwissSign Fulfillment Center can see the Swiss business identification number. If you have not restricted the visibility of your business identification number, your association data will suffice. Otherwise please give us a business identification number confirmation. Foreign associations please enclose a register extract for the confirmation.

The business identification number (UID) replaces the previous company number in the commercial register.

Since January 2011, the Federal Statistical Office (BFS) has allocated a unique business identification number (UID) with many areas of application for every economically active business in Switzerland. This enables the businesses to identify themselves with one and the same number for all contact with authorities.

The old eleven-digit commercial register number (CH-123.4.567.890-1) was replaced on 1 January 2014. Since this time, the UID has been the valid commercial register number.

 In the SwissSign SSL Gold EV certificates there has been reference to the UID since this time.

Standard SSL certificates are suitable only for securing individual domains or sub-domains. So in the case of UCC a different SSL certificate would have to be obtained and installed for each server, and this would require a lot of work.

The UCC/SAN certificate contains an extension as a special SSL certificate which allows several so-called “Subject Alternative Names” (SANs). These SANs may consist of prefixes (sub-domains) and host names. The UCC/SAN certificate therefore enables several SANs to be secured with a single certificate. The entire communication between several servers is therefore encrypted with just one single UCC/SAN certificate. The complexity with the server configuration is drastically reduced in this way.

If you install a UCC/SAN environment with MS Exchange there is always the question if you could choose for a (cheaper) wildcard certificate or if you opt for a (more expensive) Multidomain certificate. In earlier times CAs offered a special UCC/SAN certificate which allowed also internal domain names or even internal IP addresses. This type of certificate is no longer allowed.

Generally we recommend SSL Multidomain certificates for Microsoft UCC/SAN environments. Starting with Microsoft Exchange 2010 also wildcard certificates are allowed. They are also defined in Microsoft Technet. But please note that these certificates can not be used in older (<= 2007) versions or in combination with older mobile phones like Windows Mobile 5.0.

This web page gives you some good hints for the usage of wildcard certificates. Concerning Lync you will find good hints here and in special concerning the usage of wildcard certificates here.

SSL certificates are offered in three different packages:

• Single-Domain: usable only for a special website. Example: mywebsite.com.
• Multi-Domain: usable for multiple websites/domains. Example: mywebsite.com, yourwebsite.com, hiswebsite.ch.
• Wildcard: usable for any website with a specified domain name. Example: db.mywebsite.com, mail.mywebsite.com, sap.mywebsite.com etc.

Multi-Domain certificates are often called UCC/SAN certificates (Unified Communication Certificates / Subject Alternative Name) since they perfectly fit in a Microsoft Exchange or Lync environment. The SAN field of a certificate contains the further domains of a Multi-Domain certificate or the Wildcard entry of a Wildcard certificate.

Very often Multi-Domain or Wildcard certificates are chosen because they are cheaper than multiple single certificates. Copies of the same SwissSign certificate can be used on an arbitrary number of servers. By this it would be possible to secure the complete server and device farm of a company. Thus Wildcard certificates are very convenient but their use is also risky in large IT environments: If a private key is compromised or stolen on one of those many servers and be used to build up a fake additional website as man-in-the middle system it would nearly be recognized and the damage is huge since this site has also a perfect certificate based on your company name. This is also the reason why EV Wildcard certificates are not allowed.

With Multi-Domain certificates you do not have this problem. A drawback of a Multi-Domain certificate could be the performance in operation if it was filled up with a long list of domain names. In order to communicate securely servers have to exchange the certificate. If this certificate contains a long list, more bytes must be transmitted. This will not influence the performance in case 20 domains are used but 50, 100 or 200 SAN entries could sometimes end up in a performance issue.

Due to the many domain entries Multi-Domain certificates are very often updated or exchanged, if they contain a lot of SAN entries. Sometimes domains do not belong to the certificate owner and the owner of the website has to authorize the usage. If this domain cannot be used any longer, the certificate must be exchanged – on all systems.

Exactly the same happened in 2014 with the heartbleed bug detected only in OpenSSL software packages of the newer generation. All Wildcard or Multi-Domain certificates had to be renewed, also on all other websites protected by the certificate even if they were not a target of the heartbleed bug. Each change of certificate results in a downtime of the system. Also in case of end of the validity period you have to exchange the certificate on all systems and this must be planned in time before.

It is part of each decision to compare tradeoffs with risks. In small environments with sufficient control and in special for use with Microsoft UCC the usage of these certificates make good sense. Please have also a look to our special FAQ "UCC/SAN - Wildcard or Multi-Domain certificates for Microsoft Exchange?" in case you want to know which certificate you should use for a Microsoft Exchange environment.

No, unfortunately this is not allowed according to RFC 2818:

“Matching is performed using the matching rules specified by RFC 2459. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com”

We therefore recommend purchasing two wildcard certificates: one for *.mydomain.com and one for *.sub2.mydomain.com. With SwissSign wildcard certificates it is also not possible to indicate different Subject Alternative Names (SANs).

Per e-mail address. As an individual you can obtain various certificates with different e-mail addresses in each case.

Published in 2013, Certification Authority Authorization (CAA) is an Internet standard with the designation RFC 6844.

Adopting a similar structure to a large phone book, domain names are listed in a globally distributed register of names, the so-called Domain Name Service (DNS). A website with a recognisable name like www.swisssign.com is translated by this service into an Internet address such as “46.175.9.80”, meaning that it can be accessed by various Internet services (e.g. a browser). In addition to this function, the Domain Name Service also allows for the provision of additional information, such as the name and address of a website’s owner.

Thanks to the CAA standard, further information is now saved for these domains: It is recorded which certification authority is permitted to issue a certificate for the named domain. If no certification authority is recorded, any certification authority can issue a certificate. Otherwise, a certification authority cannot issue a certificate for the domain if its name is not stated here.

Why has this rule been applied?

In recent years, there has been an increasing number of “man-in-the-middle” attacks, a means of attack that is also used by secret services around the world. In order to enable them to spy on who is accessing an encrypted website, they ask an allied or compliant certification authority to issue an identical certificate for the website in question. Using this “fake” certificate, the website is then reconstructed by the attacker, with the data traffic initially being directed to the fake website by means of router manipulation. The details are then listened into and the communication is forwarded directly to the original website. In most cases, the website subjected to the attack and its visitors are none the wiser.

A CAA entry can reduce this risk by allowing for the deliberate recording of trusted certification authorities. Since September 2017, all certification authorities permitted in the browsers have been required by the CA/Browser Forum, an association of browser producers and certification authorities, to check the CAA entry prior to issuing a certificate.

Principally you can request a Gold or Silver Personal ID certificate for a team account. In each case a person must be nominated who is responsible for the keys of this group or functional account.

Please follow the regulations of the CP/CPS:

• If you bought the certificate in the webshop you should use the identifier “pseudo:” instead of the first and last name, e.g. pseudo: Sales Team.
• Email validated Silver certificates can also be used for team accounts as long the mail address is validated as existing mail address.

CAA is a process whereby the domain owner can determine which CA is allowed to issue certificates for its domain. A so-called CAA record is entered in the DNS. From September 2017, SwissSign will check all domains before issuing certificates to determine whether you have a restriction in your CAA record. Domains that have been restricted to accept certificates from certification authorities other than SwissSign are not allowed in the certificate. The certificate application is rejected. If no restriction has been placed or the CAA record names SwissSign as CA, the certificate will be authorized.

The CAA configurator supports you in defining the exact parameters for your web site.
Here are some examples depending on the DNS technology used:

Permission for SwissSign to issue certificates

Standard BIND Zone File

For BIND ≥9.9.6, PowerDNS ≥4.0.0, NSD ≥4.0.1, Knot DNS ≥2.2.0

example.com.     IN       CAA      0 issue "swisssign.com" 

Legacy Zone File (RFC 3597 Syntax)

For BIND <9.9.6, NSD <4.0.1

example.com.     IN       TYPE257  \# 20 0005697373756573776973737369676E2E636F6D

Permission for SwissSign to issue non-wildcard certificates

Standard BIND Zone File

For BIND ≥9.9.6, PowerDNS ≥4.0.0, NSD ≥4.0.1, Knot DNS ≥2.2.0

example.com.     IN       CAA      0 issue "swisssign.com"

example.com.     IN       CAA      0 issuewild ";"

Legacy Zone File (RFC 3597 Syntax)

For BIND <9.9.6, NSD <4.0.1

example.com.     IN       TYPE257  \# 20 0005697373756573776973737369676E2E636F6D

example.com.     IN       TYPE257  \# 12 0009697373756577696C643B

Permission for SwissSign to issue only wildcard certificates

Standard BIND Zone File

For BIND ≥9.9.6, PowerDNS ≥4.0.0, NSD ≥4.0.1, Knot DNS ≥2.2.0

example.com.     IN       CAA      0 issue ";"

example.com.     IN       CAA      0 issuewild "swisssign.com" 

Legacy Zone File (RFC 3597 Syntax)

For BIND <9.9.6, NSD <4.0.1

example.com.     IN       TYPE257  \# 8 000569737375653B

example.com.     IN       TYPE257  \# 24 0009697373756577696C6473776973737369676E2E636F6D

MS Outlook Webmail (OWA) does not support any e-mail certificates according to our current knowledge.

If the company entry is included in a certificate, this has to be approved accordingly by this company. The registration process guarantees that certificates with company entry are issued only if they are also wanted by the corresponding company.

Account specification swisssign.net

You only have to specify the account name on swisssign.net, if you are already a customer of SwissSign and e.g. you want to increase the number of certificates in your existing Managed PKI. The account of the Managed PKI platform swisssign.net is completely independent from the web shop swisssign.com. Therefore different account names and passwords have to be used.

Electronic order submission

The submission of the "Contract and Order for Managed PKI Services" document shall be deemed to represent a binding order for a service which is subject to a fee. The annual invoicing period begins at the end of the month after starting date of the contract, unless otherwise agreed.

The order can be submitted digitally via e-mail without a qualified electronic signature. You will receive a copy of your order in our electronic order confirmation. This constitutes the legal conclusion of the contract. A hand-written or qualified electronic signature from all signatories is only required for the Managed PKI Set-up Agreement.

Discount

The discount increases continually with the order volume and is stated precisely in the order sum calculation.

General e-mail address

If partner applications are connected to the SwissSign managed PKI platform in order to retrieve automatically certificates via the CMC or RFC 2797 interface, these applications will get a non-personal access certificate. In this case there must be an e-mail address which can receive messages concerning the necessary renewal of the certificate at the end of the lifetime. We suggest to use a non-personal, common e-mail address of your IT-department since the lifetime of these certificates is relatively long (3 or 5 years).

Multi-year Managed PKI contract

The service period of a Managed PKI is always one year. The contract will be prolonged if the contract has not been abandoned before. But it is possible to order certificates with validity periods of multiple years in your Managed PKI. In case you want to abandon the contract you have to revoke them beforehand.

Transfer of certificates

If you already purchased some certificates in the web shop we are able to transfer these certificates to your new Managed PKI account. Please enter a short hint in the notice field you can find on the end of the order form of the Managed PKI.

Domain information

There is no correlation between the domain names and the certificate types you ordered. It is possible to issue any ordered SSL certificate for any specified domain. The same with e-mail certificates.

Domain register

Services such as www.gwhois.org, www.denic.ch, www.whois.org and www.denic.de provide information on who the domain belongs to. This allows you to prove ownership.

Domain access authorisation

You prove your access authorisation by publishing a random value (secret) (on the DNS or as a TXT file on the web server), which you obtain via MPKI access. Details of this process can be found in chapter 9 of the Managed PKI user manual. 

Technical terms and contract terms

A certificate includes a specific period of validity (technical term). For the Managed PKI service, this is independent of the commercial contract term (performance period). During the performance period, certificates can thus be issued with a validity which goes well beyond the end of the performance period. The contract is unlimited in duration and may be terminated subject to a notice period of three months to the end of the one-year service period.

Revocation and re-issue

A certificate revocation (withdrawal) followed by a subsequent re-issue (e.g. employee change) only constitutes the acquisition of a single certificate.

Revocation – contract termination

At the end of the contract, those certificates which are still valid are withdrawn – either by you yourself or our Support team. Please contact us in this regard by sending an e-mail to contracts@swisssign.com or calling +41 848 77 66 55.

SwissSign maintains a general directory of all issued certificates (LDAP) on www.swisssign.net. This directory is public and comparable to a phone book. For encrypted e-mail communication, in particular, this makes sense as it allows for your communication partner to encrypt the messages it sends to you using the public key contained within the certificate.

The public directory can also be directly integrated into the e-mail programmes through the entry of parameters, making it possible to perform the encryption within the e-mail programmes through the automated retrieval of certificates.

If you would not like your certificates to be listed in the directory, select the "I do not want to publish my certificates" button. You can also subsequently change this setting subject to a fee of CHF/EURO/USD 250. However, the setting will not be applied retroactively to previously issued certificates.

Silver certificate

Silver-level certificates are shown as domain-validated certificates. The certificate shows the domain (SSL) or the e-mail-address (personal). An organisation entry is optional on personal certificates only. The Silver cerftificate allows encryption and signature, but no authentication.

Gold certificate

Gold-level certificates are shown as organisation-validated or person-validated. The certificate contains an organisation entry and, in the case of e-mail (S/MIME) certificates, a person entry. This means that encryption, signature and authentication are possible for e-mail certificates. 

SSL Gold EV certificate

Issues of SSL Gold EV certificates for you company is simply possible within the framework of the Managed PKI. These are organisation-validated and are indicated by a green bar in the browser.

Entry of independent subsidiaries

You can also issue certificates for affiliated subsidiaries, for example. For Gold certificates with an organisation entry, please note that authorisation for the use of the organisation name in the certificate must have been granted. Furthermore, all organisations must complete and sign the Declaration of Consent and Terms of Certificate Use (each with the same access managers).

The operator certificate is valid for three years.

A QWAC may only be issued if the keys have been created on a correspondingly qualified HSM. The minimum standard FIPS-140-2 level 3 is necessary for this purpose. You confirm by signing the certificate request or Managed PKI acceptance of RA policy that you ensure key generation in this way.

You can optionally add the serialNumber if the certificate holder is kept in a national personal register and the personal data of the certificate is not unique. Particularly in Scandinavian countries, personal identification number is widespread.

For authorization purposes, applications use the user name. Normally, you should enter your e-mail address. The e-mail address appears in the SAN field of the certificate.

The format is not defined by law. Generally the formats PDF, PDF/A (signature integrated in the document) or TIFF (signature in a separate file => fingerprint) are used.

The certificate does not contain the name of the requesting person but only the name of the organization and, if necessary, specifying information such as the branch or department, country of the headquarters of the organization or information on the town or canton.

Basically, the details of your organization must be provided as entered in the Swiss UID register (UID stands for the uniform Swiss company identification number). This register includes all companies or registered organisations with their headquarters in Switzerland, but is not limited to them. As not all of the data listed below are mandatory fields, we recommend that you limit yourself to these mandatory fields.
 

• Common name (mandatory field)

Same entry as in "Organization" (see below)
 

• Name of the organisation (mandatory field)

Name of the organisation according to UID register entry, e.g. "SwissSign AG". In the technical Certificate Signing Request (CSR) this value must be entered in both the attribute "Common Name" (CN) and the attribute "Organisation" (O).
 

• Country (mandatory field)

Country code ISO-3166-alpha-2, usually "CH" for Switzerland
 

• Organization identifier (mandatory field)

Prefix "NTRCH-" followed by the UID number of the organization. The UID is structured as follows:
CHE-ZZZ.ZZZ.ZZZ ("Z" stands for a digit from 1 - 9)

Example: "NTRCH-CHE-109.357.012"

In the technical CSR, this value must be entered in the "organizationIdentifier" attribute.
 

• Organization details, part 1 (not mandatory)

Any information on the organizational unit*

* Only the name of a department of the company may appear here, e.g. "Finance" or "IT", which must not lead to confusion with another organization or brand.
 

• Organization details, part 2 (not mandatory )

See above
 

• StateOrProvince (not mandatory)

Canton according to entry, e.g. "Zug
 

• City (not mandatory )

Municipality according to entry, e.g. "Baar 

A hardware security module (HSM)/cryptographic module is a hardware unit in which secret keys can be protected against unauthorized access, generated, stored and used.

Since the Organization Certificate is accepted by PDF reader (Adobe) it could be beneficial for everybody to proof the non-repudiation and integrity of a document. In this way the organization certificate can also be used by a foreign organization to show to their communication partner that the document (PDF) was not changed after signature.

In order to revoke your organization certificate on smart card (not on HSM) please visit the web page: https://postsuisseid.ch/en/support/revoking

The revocation will take place similar to the revocation of a SuisseID on smart card. You will need your PUK/PIN sheet which was supplied to you together with the shipment of your smart card. In case you do not have your PUK/PIN sheet anymore please contact our support.

Due to the adaptation of the TSA service to the new requirements of eIDAS and ZertES the resulting signature to the Adobe client is now several bytes longer than before. Adobe is not prepared to handle this. Therefore Adobe gives the hint to increase the size of the iSize value in the registry. For this please find the following example fix for Adobe Acrobat DC. We recommend to save the registry file properly before any change. Note: registry file is specific to Adobe Version and must be modified appropriately.

Copy and save text below as "fix_adobe.reg" and double-click to apply fix:

Windows Registry Editor Version 5.00

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

"iSize"=dword:00002800

Time stamps can be used as part of workflow and archiving solutions. Although every electronic signature already contains a time indication (local system time), it can be useful to connect a time certified from an external source with the data and documents. In particular as part of solutions to implement legal requirements such as the company accounts decree GeBüV, compliance rules such as SOX, Basel II or sector-specific quality frameworks like GMP. This means that it can be proven easily and indisputably at any time that the corresponding data set existed at a specific time and has not been changed since (integrity).

Technically the time stamp is a signature of the CA which contains a trusted time. The creation of this time stamp takes place via the Time Stamping Authority (TSA) according to RFC 3161. The protocol RFC 3161 defines that the query contains the hash value and this is then signed by the TSA. This ensures that the TSA service does not find out anything about the contents of the time stamped documents.

There are two possibilities: 

• By use of a suitable HSM (hardware security module) or a comparable device you can build up your own time stamping service. We can recommend you an apropriate partner solution if you like. In this case you will buy a timestamp certificate.
• You can use our powerful time stamping service directly by use of the RFC 3161 interface. Up to 20 signatures are free per day. For mor signatures you can request an offer.

To use the SwissSign Time Stamping Service you need a digital certificate. With this you can then sign a PDF document and provide it with the SwissSign time stamp. After the signature you can check the time stamp in the document by clicking on the signature and selecting “Signature Properties” and “Date/Time”.

On request the SwissSign Time Stamping Service can also be adapted according to your wishes. Please contact us for this.