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

Intermediate certificates

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

Root certificates

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

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

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

Certificate revocation lists

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

“Online Certificate Status Protocol” (OCSP).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

*This procedure is not suitable for SSL certificates! 

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

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

Certificates without a private key

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

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

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

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

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

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

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

There are two possible reasons for this:

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

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

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

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

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

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

Instructions for previous CA (swisssign.net):

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

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

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

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

• (Java) KeyStore Explorer

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

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

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

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

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

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

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

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

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

SwissSign certificates can be revoked in various ways:

For online shop customers and customers using the previous MPKI:

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

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

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

For customers using the new SwissSign CA/MPKI solution:

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

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

Either of these.

Certificates cannot be blocked temporarily (suspended).

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

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

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

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

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

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

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

In 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SwissSign will confirm receipt of the order by email.

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

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

Domain specifications

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

Domain access permission

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

Publication of certificates

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

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

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

The LDAP parameters are:

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

DV SSL Silver certificates

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

OV SSL Gold certificates

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

EV SSL Gold certificates

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

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

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

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

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

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

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

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

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

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

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

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

For more information, click here.

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

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

For Adobe Reader:

Windows Registry Editor Version 5.00

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

"iSize"=dword:00002800

For Adobe Acrobat Pro:

Windows Registry Editor Version 5.00

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

"iSize"=dword:00002800