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.

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.

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.

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

Issuance speed for SSL certificates

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

Issuance speed for S/MIME Email ID certificates

• Personal S/MIME Email ID Silver: within minutes

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

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

• Log in to your user account.

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

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

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

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

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

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

4. Share the link with the other person.

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

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

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

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

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

Please contact our support.

1. Log in to swisssign.com.

2. Search for the relevant request in your account.

3. Reprint the form.

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

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

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

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

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

For more information, click here.

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

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

For Adobe Reader:

Windows Registry Editor Version 5.00

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

"iSize"=dword:00002800

 

For Adobe Acrobat Pro:

Windows Registry Editor Version 5.00

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

"iSize"=dword:00002800