Navigate on SwissID

All customers who received their MPKI solution before 4 August 2022 are currently still on the previous CA. All online shop customers use the previous CA. The previous CA uses the swisssign.net domain.

Customers whose MPKI was set up after 4 August 2022 are using the new SwissSign MPKI solution. The new CA uses the swisssign.ch domain.

You don’t need to do anything to switch to the new SwissSign CA. You will be automatically contacted by SwissSign and guided through your migration to the new MPKI solution. If you would like to switch to the new SwissSign MPKI sooner, please contact us by emailing [email protected] and using the subject line ‘MPKI migration’

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

Intermediate certificates

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

Root certificates

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

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

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

Certificate revocation lists

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

“Online Certificate Status Protocol” (OCSP).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

*This procedure is not suitable for SSL certificates! 

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

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

Certificates without a private key

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

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

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

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

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

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

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

There are two possible reasons for this:

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

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

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

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

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

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

Instructions for previous CA (swisssign.net):

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

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

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

As a certificate chain (PKCS#7 format)

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

• (Java) KeyStore Explorer

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

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

In the technical user account on swisssign.net – ‘My certificates’ menu item, last column on the right – you can choose between ‘Private’ and ‘Publicly accessible’ under ‘Security level’. This choice affects the public part of your certificate and determines its visibility to third parties:

• Private: with this option, third parties cannot find your certificate. The certificate and subject are not listed in the SwissSign LDAP directory. Your certificate is also not published under the ‘Search for IDs’ menu item on swisssign.net. The ‘Private’ option is always selected by default.

• Publicly accessible: with this option, the certificate – subject and public key – is published and can be downloaded by anyone. This option is particularly useful if you use your certificate to encrypt messages. This way, communication partners can obtain your public key, which is necessary for encryption with you.

For server certificates (TLS/SSL), the privacy setting is not important, as they must be published in accordance with the regulations of the CA/Browser Forum; see crt.sh.

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

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

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

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

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

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

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

SwissSign certificates can be revoked in various ways:

For online shop customers and customers using the previous MPKI:

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

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

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

For customers using the new SwissSign CA/MPKI solution:

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

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

Either of these.

Certificates cannot be blocked temporarily (suspended).

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

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

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

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

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

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

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

In the electronic world, the concept of trustworthiness takes on a whole new dimension. Users must be able to clearly identify the communication partner.

A digital (or electronic) certificate is an electronic credential that links a signature verification key to the name of a person, organisation or server. Or, in other words, a certificate is a non-changeable ‘electronic identity card’ that the user can use for identification and/or encryption purposes online.

Identification: certificates are used

•  to identify who is sending information.
•  to identify the server a user is connected to.
•  to identify the user connected to a server.

Encryption: digital certificates contain the certificate holder’s public key. This can be used by its counterpart to encrypt an email or document sent over the internet.

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

The most basic set contains the following:

• The public key of the certificate holder (person, computer/machine or organisation)

• Information about the certificate holder

• Information about the issuer of the certificate, i.e. the CA or organisation that provided the certificate

• This certificate’s digital signature by the issuer

• The certificate’s issue and expiry dates

• The certificate’s serial number

• SwissSign certificates also contain information about the CP and CPS

Using a certificate guarantees security, data protection and trust. Certificates are used in various applications, including secure email, e-business, e-government and e-health. 

You can find out more in the ‘Partner solutions’ section of our website. 

The asymmetric, cryptographic procedure uses a key pair. This cryptographic key pair consists of a public and a private key. Data that is to be encrypted with one of these keys can only be subsequently decrypted with the other key. This cryptographic method can be used for both encryption and technical signatures.

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

In the case of the technical signature, the data is encrypted for the recipient by the sender’s private key and can then be verified by the recipient using the public key.

The public key is publicly accessible through the certificate. This key is used to encrypt data or to confirm the signatory’s digital signature (identification). Data encrypted with the public key can only be decrypted with the associated private key.

The private key is only known to, or may only be accessible to, the certificate holder. It is used to decrypt data and to create a digital signature.

The certificate contains a ‘Key usage’ entry. This field defines the use for the certificate. Possible entries for the key usage are: digital signature, non-repudiation/content commitment, key agreement, encryption and/or data encryption.

Every digital certificate goes through the following life cycle:

• Certificate application: a user applies for a certificate.

• Application check: the registration authority (RA) checks the user’s/applicant’s identity.

• Generation/issuance of the certificate: the certificate authority (CA) issues the certificate. This certificate contains information about the holder, issuer, permitted use and lifetime (valid from and valid to dates)

• Revocation/invalidity: the certificate is revoked or declared invalid before expiry.

• End of certificate term: the lifetime of the certificate has expired.

• Certificate renewal or ‘Rekey’: renewal of the certificate.

Trust is the underlying principle of every security model. This is the same for the public key infrastructure (PKI). To be able to work with certificates at all, the CA that issued the certificate must be trusted.

PKIs are always organised hierarchically. The top level of the hierarchy (root) must be explicitly filed as trustworthy so that the content of the corresponding root certificate is trusted.

SwissSign root certificates are recognised as trustworthy, i.e. they are filed in the following root trust stores, among others: Microsoft, Mozilla (NSS) and Apple OS X. You can see the distribution of SwissSign root certificates.

The SwissSign certificates are therefore displayed as trustworthy to the end user of these applications. Thus, as soon as a PKI’s root certificate is filed as trustworthy, every sub-certificate of this hierarchical root can be securely verified.

Trusting a CA such as SwissSign also means trusting the various processes associated with the PKI, such as user registration or certificate validation (CRL, OCSP). The Certificate Policy and Certification Practice Statement (CP and CPS) bring transparency to the processes and help strengthen trust. You can thus determine your trust in the SwissSign CA by reading the relevant CP and CPS. SwissSign is also a qualified certification service provider (CSP) under Swiss law that meets the requirements set out in the Swiss Federal Act on Electronic Signatures (”ZertES”). For its part, the ZertES complies with the strictest international standards in this field.

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

A public key infrastructure (PKI) is an infrastructure or environment where various applications and functions are executed with cryptographic keys (public and private keys) and certificates. These applications range from access controls and secure email applications to various types of digitally signed information related to the CA or RA.

A certificate authority (CA) is a provider of certification services or a certification authority – a trusted third party. In some cases, reference is also made to a certification service provider (CSP).

SwissSign is a CA – a body that confirms the data of individuals, organisations or machines within an electronic environment and issues digital certificates for this purpose.

A registration authority (RA) is a service provided by SwissSign that consists of verifying the identity and, if necessary, the attributes of each applicant for a certificate before the CA generates the corresponding certificate or assigns the data to activate the use of the signature key.

The certificate policy (CP) is a document from the certification service provider (CSP) that describes the rules that apply to a certificate type (‘what should be achieved’). It comprises the set of rules that prescribe a certificate’s usability for a certain group of people and/or a class of special applications with common security requirements. It is used by third parties to analyse trustworthiness.

The CPS makes statements about certification practice (i.e. how the requirements are implemented).

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

You can find these documents in the https://www.swisssign.com/en/support/repository.html

Manufacturers of browsers, operating systems, mail clients and other software that evaluates certificates must maintain a program wherein they manage the CSPs they recommend to their customers as trustworthy CSPs (root store program).

Maintaining your own root store program is time-consuming. It includes maintenance of the requirements documents and the recorded CSPs. That is why the CA Browser Forum is responsible for maintaining the minimum requirements documents. The root store program maintainers (software manufacturers) and the CSPs are represented in this committee and jointly develop and maintain the requirements documents.

The root store programs are mainly based on the ‘baseline requirements’ by the CA Browser Forum. www.cabforum.org

The Certificate Transparency (CT) security procedure is intended to identify incorrectly operating certification authorities and exclude them from secure internet communication. The process, driven by Google Chrome, is an important cornerstone of trusted internet communication.

Basic concept: all certificates used for secure internet communication have to be registered in a cryptographically protected log system and managed by at least three central log servers distributed around the world. Subsequent changes, conspicuous and inadmissible registrations, false certificates, additions or other manipulations of a certificate that has already been registered would thus be impossible or would be recognised immediately by any browser.

SwissSign fully supports Certificate Transparency with its SSL certificates.

In the issuer’s corresponding CP and CPS, you can read which quality the certificate holder (sender) has been identified with by the issuer. In this way, the sender’s authenticity is proven by a valid and trustworthy signature. However, it is still advisable to be suspicious of unknown senders, especially if the publisher of the signature is also unknown.

Emails are encrypted with the recipient’s public key and decrypted with the private key. The certificate is used for signing.

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

• Certificates are renewed, but someone forgets to install the expired old certificate as well. All old stored emails can no longer be read. Access after certificate expiry.

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

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

The SSL certificate with its asymmetric keys is only used for uniquely and securely identifying the server, for mutual authentication. For legacy applications, the certificate is also used for encryption.

The certificate is issued in accordance with the RFC 5280 standard. The more recent standard requires registration in the Subject Distinguished Name as well as in the Subject Alternative Name (SAN). Most mail applications on the market pay particular attention to the latter. Placement of the email address in the emailAddress attribute of the Subject Distinguished Name is obsolete and is no longer used by SwissSign.

RFC stands for ‘request for comments’. RFCs are a set of technical and organisational documents from the RFC editor that are generally and internationally accepted as internet standards. The RFC system was initiated in 1969.

To find out more, visit www.rfc-editor.org.

Certification Authority Authorisation (CAA) is an internet standard published in 2013 called RFC 6844.

Rather like a large phone book, domain names are listed in a globally distributed register of names called the Domain Name Service, or DNS for short. This service converts a website with a recognisable name, such as www.swisssign.com into an internet address such as ‘46.175.9.80’ to make it accessible to various internet services, such as a browser. The Domain Name Service allows various additional information, such as the name and address of a website’s owner, in addition to the conversion.

Through the CAA standard, more information is now stored for these domains: the certification authority that may issue a certificate for the named domain is recorded. If no certification authority is registered, anyone may issue a certificate; otherwise, a certification authority may not issue a certificate for the domain unless its name is mentioned there.

CAA is a procedure in which the domain owner can determine which CA may issue certificates for their domain. For this purpose, a CAA record is entered in the DNS. From September 2017, SwissSign will check all domains before issuing certificates to see whether you have a restriction in your CAA record. Domains that have been restricted from accepting certificates from certification authorities not named SwissSign are not permitted in the certificate. The certificate request is rejected. As long as no restriction has been applied or the CAA record allows SwissSign, the certificate will be approved.

The CAA Configurator helps you find the perfect settings for your website.

Here are some examples depending on the DNS technology used:

Permission to issue certificates for SwissSign

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

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 domain validation, it will be difficult to obtain confirmation of the owner, which is also verifiable.

Yes, they can. To purchase an SSL Gold EV certificate, associations also have to provide a registration number.

In Switzerland, just like companies, associations can apply for a company ID (UID). This is not to be confused with the EU VAT ID (EU-UID). Associations with an annual turnover of less than CHF 150,000 are exempt from VAT, but can obtain a company ID on request. This UID is to be entered as a registration number in the certificate.

German associations are recorded as registered associations in the association register and can use this number.

SwissSign can view the Swiss UID. If you have not restricted the visibility of your UID, your association details are sufficient. Otherwise, please provide us with a UID confirmation. Foreign associations should enclose an extract from the register for confirmation.

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

The Swiss Federal Statistical Office (FSO) assigns a unique and universal company identification number (UID) to every economically active company in Switzerland. This enables companies to identify themselves with the same number for all interactions with authorities.

Since this was introduced, the UID has been referenced in the SwissSign SSL Gold EV certificates.

There are essentially three types of SSL certificate:

• Single domain: can only be used for specific websites. Example: mywebsite.com.
• Multi-domain: can be used for various websites/domains. Example: mywebsite.com, yourwebsite.com, hiswebsite.ch.
• Wildcard: can be used for any website with a specified domain name. Example: db.mywebsite.com, mail.mywebsite.com, sap.mywebsite.com, etc.

Multi-domain certificates are also often called UCC/SAN (Unified Communication Certificates/Subject Alternative Name), as they are intended for use with Exchange in a Microsoft environment. The SAN field of the certificate contains an entry for multi-domain and wildcard certificates that refers to the other domains or the wildcard.

Very often, multi-domain or wildcard certificates are also used because of their lower price. Copies of the same SwissSign certificate can be used on different servers as required. In this way, an entire company environment can be secured with just one wildcard certificate. The possibilities with a wildcard certificate may be very convenient, but they can also be risky in large company structures. If a private key for this certificate is compromised on one of the many servers and a fraudulent website with its domain name is activated as man-in-the-middle, this is barely noticeable and causes considerable damage. Especially since this fraudulent site is perfectly protected with a certificate from the company. Therefore, wildcard certificates should not be offered with the EV standard.

Multi-domain certificates do not have this problem.

With the many SAN entries, however, there is an increased risk that the multi-domain certificate will have to be replaced prematurely, since the domains often include domains that do not belong to the holder and for which an authorisation had to be issued at the time of issue. If a domain is dropped, the certificate becomes invalid and any multi-domain certificates used must be replaced.

As with any decision, the benefits, dangers and risks must be weighed up. There are certainly good reasons for using these certificates in small, manageable environments or in Microsoft UCC environments. Please also see our additional FAQ ‘UCC/SAN – wildcard or multi-domain for Microsoft Exchange?’ regarding use in a Microsoft Exchange environment.

No, this is not permissible under RFC 2818.

We therefore recommend purchasing two SSL wildcard certificates – one for *.mydomain.com and one for *.sub2.mydomain.com. With SwissSign SSL wildcard certificates, it is also not possible to specify different alternative names (SAN).

The old CA platform offers the option of including the "base domain" (e.g. "swisssign.com") in addition to the wildcard domain (e.g. "*.swisssign.com"). The new CA platform also offers this option. To do this, proceed as follows during an application process for a wildcard certificate:

• Click the "+Add element" button under the "DNS" section.
• Enter the wildcard entry in the "DNS1*" field, e.g. "*.swisssign.com".
• Enter the base domain entry in the "DNS2*" field, e.g. "swisssign.com".
• Continue with the issuing process as usual.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SwissSign will confirm receipt of the order by email.

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

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

Domain specifications

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

Domain access permission

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

Publication of certificates

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

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

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

For the previous CA, the LDAP parameters are:

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

For the new CA, the LDAP parameters are:

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

DV SSL Silver certificates

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

OV SSL Gold certificates

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

EV SSL Gold certificates

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

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

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

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

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

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

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

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

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

Issuance speed for SSL certificates

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

Issuance speed for S/MIME Email ID certificates

• Personal S/MIME Email ID Silver: within minutes

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

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

Log in to your user account.

• Select ‘My licences’ and start the activation of the desired certificate by clicking on ‘Activate code’.
• You will now be taken to the technical application for your certificate. To do so, follow the instructions in the application process.
• Once your application has been reviewed and accepted, you will receive an email with the link to download your certificate.

Instructions: How do I redeem a certificate licence on swisssign.net? (PDF, 1 MB)

• Log in to your online shop user account at swisssign.com and continue to your certificate vouchers.

• Select the certificate voucher you want and click on ‘Send activation link’ to send the certificate voucher to someone. An email is prepared interactively with your entries for the recipient of the certificate voucher and can then be sent.

• Shortly afterwards, they receive an email containing the personal message and a link that allows them to use the certificate immediately on swisssign.net.

Yes. In the instructions entitled ‘How do I request my certificate license?’ on www.swisssign.net (PDF), page 7, you will find a sample confirmation email with a link to download the certificate.

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

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

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

For DV SSL Silver and Personal S/MIME Email ID Silver certificates, electronic validation is carried out by email to the desired address. You will not receive this email if, for example, you do not set up the email account until after the application.

If you’ve created an account on swisssign.net, proceed as follows:

• Log in to swisssign.net.
• Search for the relevant certificate request. If you click on ‘Search’ without entering anything in the search field, all your certificates and certificate requests will be displayed.
• Click on ‘Attribute’ next to the relevant certificate request.
• A new window with the ‘Approval’ section will be displayed.
• Select ‘Send proof of ownership email’.
• The validation email will be sent again.

If you haven’t created an account on swisssign.net, proceed as follows:

• Log in to your online shop user account at swisssign.com and continue to your licenses.
• Select the relevant license and click on ‘Activate code’.
• Because you have already converted the licence into a certificate request, you’ll receive the following error message: ‘This certificate has already been requested’.
• Select the ‘Search for previous requests’ link below the error message. You’ll be redirected to swisssign.net.
• The search window with your pending certificate request will be displayed.
• Click on ‘Attribute’ next to the relevant certificate request.
• A new window with the ‘Approval’ section will be displayed.
• Select ‘Send proof of ownership email’.
• The validation email will be sent again.

• You can approve DV SSL Silver certificates and Personal S/MIME Email ID Silver certificates yourself by clicking on the approval link in the email you receive. Sometimes, this email is triggered before the relevant email account has been created.

• Complete the following steps to re-trigger the email:
  a) Log in to your account at swisssign.net and click on the ‘Search’ button. 
  b) If you don’t have a swissign.net account, Enter the relevant license for the certificate request in the search field and click on the ‘Search’ button.

• In both cases, the certificate request will be displayed in a results table. You’ll see an ‘Attribute’ button next to your entry. Click on the button. On the next page, under the ‘Approval’ section, you can click on the ‘Proof of ownership email’ to re-send the email.

If you’ve created an account on swisssign.net, proceed as follows:

• Log in to swisssign.net.
• Search for the relevant certificate request. If you click on ‘Search’ without entering anything in the search field, all your certificates and certificate requests will be displayed.
• Select ‘Attribute’ next to the relevant certificate request.
• A new window with the ‘Approval’ section will be displayed.
• Click on the link next to ‘Registration document’.
• The request form will be displayed again.

If you haven’t created an account on swisssign.net, proceed as follows:

• Log in to your online shop user account at swisssign.com and continue to your licenses.
• Select the relevant license and click on ‘Activate code’.

Because you have already converted the licence into a certificate request, you’ll receive the following error message: ‘This certificate has already been requested’.

• Select the ‘Search for previous requests’ link below the error message. You’ll be redirected to swisssign.net.
• Select ‘Attribute’ next to the relevant certificate request.
• A new window with the ‘Approval’ section will be displayed.
• Click on the link next to ‘Registration document’.
• The request form will be displayed again.

If you received your certificate through the swisssign.com online shop or one of our online shop partners, please send us a digitally signed email to [email protected].

Umlauts are not displayed correctly in Excel after a CSV export (e.g. in search results on the swisssign.net platform).

Excel does not open the file as a UTF-8-encoded file, which causes umlauts to be displayed incorrectly in Excel. To avoid this problem, we recommend taking the following steps:

1. Save the exported CSV file locally as a CSV file
2. Open Excel and select ‘From text’ under the ‘Data’ tab
3. Select the CSV file you saved
4. In the first window of the import wizard, enter UTF-8 as the file source

The umlauts will then be displayed correctly in Excel.

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

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

SwissSign certificates can be revoked by online shop customers in various ways:

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

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

3. Offline revocation: the offline revocation form is available for this purpose.

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

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

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

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

For more information, click here.

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

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

Windows Registry Editor Version 5.00

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

‘iSize’=dword:00002800