The issuance speed for BlueCerts powered by SwissSign certificates depends on the certificate type and reaches from a few seconds up to 10 business days for certificates, which require an intensive manual verification of the requester, of the organization or of the domain. These deadlines are valid after reception of the registration documents by BlueCerts and can be held under the exclusive condition that all documents are correct and complete.
An exception are those certificates with automated issuance, which do not require submission of documents (eg. domain-validated-only SSL). These certificates are usually issued immediately.
Issuance speed for SSL Certificates:
- BLUE SSL DV: a few seconds or minutes
- BLUE SSL DV Wildcard: up to 2 business days
- BLUE SSL OV: up to 2 business days
- BLUE SSL OV Wildcard: up to 2 business days
- BLUE SSL EV (Extended Validation): 5 to 10 business days
Issuance speed for Personal Certificates:
- BLUE E-MAIL Certificat: up to 2 business days
- BLUE E-MAIL Certificat Pro: up to 2 business days
- BLUE E-MAIL Certificat Organization Pro: up to 2 business days
Issuance speed for Organization Certificates:
- PostCertificate for Organizations: 5 to 10 business days (except hardware delivery outside Switzerland)
- BlueCerts powered by SwissSign Certificate for Organizations: 5 to 10 business days
These deadlines are standard values and may be subject to extraordinary exceptions (eg. important workload of the registration authority).
On account of regulations in Switzerland, SwissSign is unfortunately not permitted to issue certificates for the following countries:
- Algeria
- Belarus
- Central African Republic
- Cuba
- Democratic People’s Republic of Korea
- Democratic Republic of the Congo
- Ecuador
- Eritrea
- Guinea
- Guinea-Bissau
- Iraq
- Islamic Republic of Iran
- Ivory Coast
- Lebanon
- Liberia
- Libya
- Myanmar (Burma)
- Somalia
- Sudan
- Syria
- Yemen
- Zimbabwe
The issue of certificates is prevented here where possible. Certificate requests or the issue of certificates for these countries can also be immediately withdrawn in retrospect.
You can protect your web sites agains man-in-the-middle attacks. In case of man-in-the-middle attacks an agressor uses the copy of your web site and protects it agains a false certifcate. He manipulates the router and redirects the data targeted for your web site to his own web site. Mostly the agressor listens only to the information and redirects it immediatly to your web site.
This mechanism is complex due to the necessary manipulation of router equipment. Thus it is frequently used by secret services. By use of certificate pinning you can be sure that the visitor of your web site can only call your web site if he finds the certificate you already installed.
Manual certificate-pinning (PDF, 98 KB)
Basically the end customer or partner has no entitlement to reimbursement or credit according to the general terms and conditions. In all cases it is therefore always a concession on the part of BlueCerts.
However we have seen that customers are very satisfied with their BlueCerts powered by SwissSign certificates and currently act according to the following goodwill regulations: within 30 days of issue, every customer has the choice of a refund or a 100% voucher at the amount of the purchased and revoked (withdrawn) certificate.
After 30 days the customer receives a voucher for the remaining period of validity of the certificate in question in the event of revocation.
Of course, this does not affect the warranty obligation of BlueCerts regarding advice and the issuing of certificates.
The root certificates of SwissSign are installed in most commonly used browsers. Update your browser to the latest version and install the latest root certificates from the Windows Update page. Dissemination of the SwissSign certificates
It is also possible that your web server does not send the complete certificate chain to clients. This problem can be solved by using the SSLCertificateChainFile function in the Apache configuration.
With BLUE SSL DV certificate, BlueCerts checks the domain entered in the certificate request. Checking this is called “proof of possession”. In the certificate request process the applicant can choose who receives the e-mail on domain membership. The following selection can be made via radio button:
- admin@indicateddomain
- administrator@indicateddomain
- hostmaster@indicateddomain
- postmaster@indicateddomain
- webmaster@indicateddomain
The “proof of possession” e-mail is sent to the e-mail address selected here. When the link contained in this e-mail is clicked on, the certificate is issued.
You receive e-mails like the following:
Dear operator,
The automatic CRL issuance for CA ‘Silver Personal G3’ failed. Please use the following link to do it manually: https://swisssign.net/cgi-bin/auth/ca?_crl=do&;selected=Silver Personal G3
Regards,
Your SwissSign Team
Please ignore this, we are examining the error and will rectify it at once.
Intermediate certificates help complete a ″Chain of Trust″ from your purchased e-mail client certificate to the trustful SwissSign root certificate.
As far as SwissSign generated your private and public key pair the client certificate and intermediate certificate are already bundled in the ′p12′ file you downloaded.
If you did a registration on swisssign.net where you provided a CSR you may need to download the format with the complete chain of trust including the issuing certificate. We offer different formats in the download area. Please pay attention to download the format with the complete chain which is clearly indicated (′p7c′, ′pem′).
You requested SwissSign to generate a private and public key during the certificate request. The private key was immediately encrypted via the transfer password. The password must be entered e.g. during every installation of the certificate. As far as this password is not known anymore SwissSign is not capable to help you. Secured by internal processes and algorithms the password cannot be decrypted and also a reset is not possible. Unfortunately you have to order a new certificate and to keep your password safe.
- First of all in the Synology system a CSR (Certificate Signing Request) needs to be created. This means that the key pair has also then been created on the Synology server.
- After the issuance, the certificate should be downloaded in the format “.pem” from www.swisssign.net. All other formats can cause error messages, e.g. “File encoding must be saved as UTF-8”.
- The intermediate certificate (type G22) should be downloaded from the download page.
- Now on the Synology server the files “private key” (locally generated) and also the certificate in pem format and the intermediate certificate in perm format can be loaded.
No, revoked certificates or certificates declared invalid also remain on the Certificate Revocation List (CRL) after the expiry date indicated in the certificate. The reason is that for the validation of the signature it is important to know when a certificate was revoked.
There are different tools for reformatting. One of the best known ones is www.openssl.org:
- Convert a certificate from PEM to DER format: openssl x509 -in cert.pem -inform PEM -out cert.der -outform DER
- Convert a certificate from DER to PEM format: openssl x509 -in cert.der -inform DER -out cert.pem -outform PEM
SwissSign Extended Validation certificates are displayed green in most current browser types.
Most browsers and operating systems have dynamic root updates (e.g. Microsoft, Opera). In these cases, no manual software updates are required by the user. For other cases, where no green address bar appears, please proceed with the following steps one after the other (explained with the IE9):
- Carry out a ″Windows Update″, empty the browser cache and test again by entering www.swisssign.com in IE9.
- If the measure listed under 1 does not work, carry out the following steps. Important note: you need administrator rights on your computer to perform this action.
- Close Internet Explorer IE9
- Go to the Start menu and to Run, type ″certmgr.msc″ and press ″Enter″.
- Under ″Trusted Root Certification Authorities/Certificates″ delete ″SwissSign Gold CA – G2 certificates″.
- Test again by entering www.swisssign.com in IE9. In IE9 go to Tools / Internet Options / Advanced / and select ″Restore Defaults″.Please note that certain individual settings will be reset by doing this (observe instructions of IE). Test again by entering swisssign.com in IE9.
The e-mail is encrypted with the help of the recipient certificate. This means it is necessary for the sender to receive the certificate of the recipient. This can be done manually or also by a corresponding secure mail gateway collecting the certificates from incoming e-mails.
The main web browsers all naturally support OCSP stapling:
You will also find further information here.
Here we absolutely recommend upgrading the system or replacing it so that SHA-2 certificates can also be used. The new provisions of the CA Browser Forum stipulate that Certification Authorities may only issue short-term certificates based on SHA-1. For major customers with several certificates, SwissSign offers this service to issue certificates with a period of validity of several months for a transition period. This is done on a project basis, i.e. for this we need a precise list of the certificate types and the number and can then make an offer.
Basically we also offer to withdraw and reimburse the SHA-2 certificate if this cannot be used.
If you are using SHA-2 SSL certificates, your customers with older operating systems or browsers can maybe no longer open your websites: this concerns, for example, all customers who are still using Windows XP systems with Service Pack 2 and have not updated to Service Pack 3.
The new Windows systems support all SHA-2. Unfortunately we are only a supplier of certificates which will be issued in a standardized form. If these certificates are accepted by all operation systems, applications and different versions is difficult to say. There are too many systems and versions on the market. Please apologize that we cannot support you in detail. Please contact your supplier of your operation system or application for more details. We would just like to communicate the information we got from operation system and application vendors (without any warranty):
Java-based web servers support SHA-2 as long as Java SDK 1.4.2 or higher is used.
Apache-based servers should be based on an Apache version 2.x or higher. For the key generation at least Open SSL 1.1.x should be used.
Older specific hardware, e.g. point of sale systems, could also have problems. Here you need to ask the manufacturer in good time whether these systems can be updated to a current software version.
In detail the operating system and software producers have given the following recommendations about which system versions support SHA-2 (reproduced subject to correction):
Operating systems
- Windows from version XP SP3
- Windows Phone from version 7
- Windows Server from version 2003 SP2 including hotfixes
- Android from version 2.3
- Apple OS X from version 10.5
- Apple iOS from version 3.0
- Blackberry from version 5.0
Server systems
- Apache from version 2.0.63 with OpenSSL 0.9.80; higher version recommended because of Heartbleed.
- JAVA from version 1.4.2
- Mozilla NSS from version 3.8
- Oracle Weblogic from version 10.3.1
- IBM Domino Server: support starting with version 9.0.1 FP2
- Citrix: see detailed list
- IBM http Server from version 8.5
Browsers
- Internet Explorer from version 6, with Windows operating system from version XP SP3
- Mozilla from version 1.4
- Firefox from version 1.5
- Chrome from version 26
- Netscape from version 7.1
- Opera from version 9.0
- Safari from version 3
E-mail applications
- Outlook 2003/2007 with Windows XP SP3: cannot verify and send a SHA-2 signed e-mail.
- Outlook 2007 and higher: Supports SHA-2.
- Mozilla Thunderbird 24 with Windows XP SP3: Can verify SHA-2 signed e-mails. With SHA-1 there were generally problems with sending signed e-mails.
- IBM Notes 9, IBM Notes basically also supports SHA-2 but has problems with the verification of signed e-mails.
There are basically two possible reasons for this:
- When establishing SSL encryption or also in e-mail systems the installation of an intermediate certificate was forgotten.
- The customers run a so-called «SSL Inspection» in their proxy. This is a function which breaks the encrypted connection and checks the communication for unpermitted contents or even malware during the download process. SSL Inspection generally works with non-trusted, own certificates. This means not only pages with SwissSign certificates but also other pages are affected. The problem is generally solved by configuring the affected page from the proxy.
Often these problems are not based on missing or defective root certificates in the operating systems or browsers but rather when establishing SSL encryption or also in e-mail systems the installation of an intermediate certificate was forgotten.
Certificates are arranged hierarchically: The certificate itself trusts an intermediate certificate, if necessary this trusts another intermediate certificate etc. Ultimately the intermediate certificates also trust the root certificates which are listed in the browsers and operating systems. Since the browsers and operating systems contain only the root certificates, the chain of trust is broken without intermediate certificates.
In the Windows environment these problems occur more rarely because Microsoft Windows or the Windows browsers try to store intermediate certificates on a temporary basis as soon as a page, for example, has been accessed with the correct installation of a BlueCerts certificate. This temporary storage is then automatically used if the intermediate certificate has not been installed correctly and the user is not at all aware of the «error». With Linux, however, the missing configuration becomes evident immediately.
This can be corrected by downloading the entire certificate chain and installing the certificate chain including intermediate certificates.
- To do this, please go to the link you received during the certificate issue process in order to download the certificates. Alternatively you can also look for your certificate on swisssign.net and then press the «Download» button.
- In the available download formats select the file with the ending .p7c or .pem (entire certificate chain). All other downloads – including the .p12 file – contain no intermediate certificates.
Revocation is the process that makes a certificate invalid. Revoked certificates are listed in the Certificate Revocation List (CRL), and the CRL is published by the CA as per the corresponding CP/CPS (Certificate Policies CP/Certificate Practice Statements).
When an encryption certificate is revoked, it is extremely important that you store the corresponding private key. You will still need this key to decrypt data that was encrypted using the old (revoked) certificate. When a signing certificate is revoked, you can safely delete the private key, because you can no longer use it to create valid signatures.
Technically the certificate has to be issued again when the content is changed, and this involves costs. With the current price structure the charge is per valid subject if the number of issued certificates remains within a fair framework.
Since 1 April 2015, CAs have no longer been able to issue 5-year SSL certificates. If, after this period, the customer uses certificate licences which were purchased before, we are obliged to withdraw these licences. Affected customers can have their certificate reimbursed by us or receive a 3-year certificate and a voucher to purchase another certificate. Please contact our support team here.
With suspension the validity of a certificate is temporarily suspended.
BlueCerts does not offer temporary blocking of certificates. The reason is that blocked certificates go on a revocation list (CRL) and have to be removed again later. So afterwards the timeframe in which a certificate was suspended cannot be tracked. With qualified certificates temporary blocking is also prohibited by law.
When issuing a certificate it is given a fixed period of validity. This means you have to request a new certificate upon expiry. Here we have to check if the desired certificate content is still valid. To prevent certificates being exchanged annually, we recommend that you purchase certificates with longer validity periods (max. 5 years).
An extremely secure process is used for generation. The basis is a random generator which is provided with many random events which cannot occur again. Here random, current status information is used by processes, different time stamps, process numbers, etc. This very complex random process is carried out once for every key and is therefore unique.
The public key procedure is an asymmetrical, cryptographic procedure in which a pair of keys is used. This cryptographic pair of keys consists of a public and a private key. Data encrypted with one of these keys can only be decrypted with the other key. This cryptographic method can now be used both for encryption and also for technical signatures.
In the case of encryption, the data are encrypted for the recipient with the public key (key in the certificate) and can now be decrypted only with the corresponding private key.
In the case of the technical signature the data are encrypted for the recipient with the private key of the sender and can then be checked by the recipient with the help of the public key.
The public key is publicly accessible via the certificate. This key is used for encrypting data or confirming the digital signature of the signatory (identification). Data encrypted with the public key can be decrypted only with the corresponding private key.
The private key is known only to/may be accessed only by the certificate holder. It is used for decrypting data and for creating a digital signature.
A root certificate is a certificate signed by a CA (Certification Authority). To use a root certificate you must first trust the corresponding CA. Using a root certificate infers that the user instance recognizes and accepts all certificates issued by the relevant CA.
For a detailed description of CA usage, organization, functions, methods and processes, see the SwissSign Certificate Policy CP/Certification Practice Statement (CPS): Repository
Trust is the basic principle in every security model. This is also the case with the public key infrastructure (PKI). To be able to work with certificates at all, the CA which issued the certificate has to be trusted.
PKIs are always organized hierarchically. The top level of the hierarchy (root) has to be stored explicitly as trusted so that the content of the corresponding root certificate is trusted.
The SwissSign root certificates are recognized as trusted, i.e. they are stored in places including the following root trust stores: Microsoft, Mozilla (NSS) and Apple OS X (dissemination of SwissSign root certificates). The BlueCerts powered by SwissSign certificates are therefore displayed as trusted to the end user of these applications. So as soon as the root certificate of a PKI is stored as trusted, every subcertificate of this hierarchical structure can be safely checked.
Trusting a CA like SwissSign also means trusting the various processes belonging to the PKI, such as user registration or certificate validation (CRL, OCSP). The certificate policy and certification practice statements (CP/CPS) bring transparency to the processes here and help reinforce trust. You determine your trust in the SwissSign CA by reading the corresponding CP/CPS. SwissSign is also a qualified Certification Service Provider according to Swiss law which meets the requirements of the Swiss Federal Act on Electronic Signatures (ZertES). ZertES in turn corresponds to the strictest international standards in this area.
Finally also import the corresponding SwissSign root certificates into your programs to establish the relationship of trust.
A public key infrastructure (PKI) is an infrastructure or environment where various applications and functions work using cryptographic keys (public key and private key) and certificates. These applications range from access control and secure e-mail through to various types of digitally-signed information relating to the CA or RA.
The Certificate Policy (CP) is a document of the Certification Service Provider (CSP) that describes the various actors of a Public Key Infrastructure (PKI) and their roles and obligations. It comprises all rules which stipulate the applicability of a certificate for a specific group of people and/or a class of specific applications with shared security requirements. Third parties use it to analyse trustworthiness.
When in use with X.509 certificates (all SwissSign certificates), a specific field can be set to include a link to the associated certificate policy. Thus, during an exchange, any relying party has an access to the assurance level associated with the certificate, and can make a decision concerning the level of trust to put in the certificate.
CPS means Certificate Practice Statement, i.e. statements about the rules and guidelines which are effectively implemented by SwissSign for issuing certificates. The CPS defines the equipment, policies and procedures used by providers of certification services in accordance with the certification policy selected by them. The CPSs correspond with international standards based on RFC3647.
CP and CPS form the legal basis for the relationship between the certificate holders and SwissSign.
Microsoft announced in November 2013 that from January 2016 it will no longer accept Code Signing certificates and SSL certificates with SHA-1 as trusted.
SHA-2 consists of several cryptographic hash algorithms developed by the National Institute of Standards and Technology (NIST) which are going to replace the weaker SHA-1 hash algorithm.
Google also announced in September 2014 that probably from January 2015, in all versions of the Google Chrome browser, websites which are protected with certificates which are still valid after 1 January 2016 and are based on the SHA-1 algorithm will be displayed as unsafe.
In the virtual world the term trust has a new dimension. Users must be able to clearly identify their communication partner.
A digital or electronic certificate is an electronic confirmation which links a signature validation key with the name of a person, organization or a server. Or in other words: a certificate is an unchangeable “electronic identity card” which the user can use for identification and/or encryption on the internet.
Identification: certificates are used
- in order to identify the sender of information.
- in order to identify the server with which a user connects.
- in order to identify the user that connects with a server.
Encryption: digital certificates contain the public key of the certificate holder. This can be used by the user’s counterpart in order to encrypt an e-mail or a document sent via the internet.
Certificates also play an important role in secure web transactions such as https (SSL certificates).
There are various types of digital certificates. The minimum set contains the following:
- The public key of the certificate holder (person, computer/machine or organization)
- Information on the certificate holder
- Information on the issuer of the certificate, i.e. on the CA or the organization that delivered the certificate.
- Digital signature of this certificate by the issuer
- Delivery and expiry date of the certificate
- Serial number of the certificate
- Certificates from SwissSign also contain information on the CP/CPS.
At BlueCerts an extremely secure process is used for generation. The basis is a random generator which is provided with many random events which cannot occur again. Here random, current status information is used by processes, different time stamps, process numbers, etc. This very complex random process is carried out once for every key and is therefore unique.
Producers of browsers, operating systems, mail clients and other pieces of software that evaluate certificates have to maintain a program by managing the CSPs that they recommend to their customers as trusted CSPs (root store program).
A lot of work is required to maintain your own root store program. It comprises maintaining the requirements documents and the incorporated CSPs. Maintaining the minimum requirements documents is therefore the responsibility of the CA Browser Forum. In this body the root store program maintainers (software producers) and the CSPs are represented and compile and maintain the requirements documents together.
Today more and more root store programs are based on the ″baseline requirements″ of the CA Browser Forum. www.cabforum.org
The certificate contains the public key. If, for example, Alice wants to send you a confidential e-mail and use the public key procedure here, she needs your public key. One of the tasks of a CA is to also make the public keys publicly accessible.
BlueCerts powered by SwissSign offers you three privacy levels. In the technical user account on www.swisssign.net (search the certificate and press „attributes“), under the entry «Privacy» you can select between “Private”, “Public Lookup” and “Public Download”. If you have not created an account on swisssign.net, you can directly search your certificate with the license code purchased at the purchase and make the selection via “Attributes”. This selection option concerns the public part of your certificate. You yourself therefore determine the visibility of your certificates for third parties.
Here you should read the document Information on the legal significance of SwissSign certificates (PDF, 271 KB).
Every digital certificate has the following life cycle:
- Certificate request: a user requests a certificate.
- Request check: the Registration Authority (RA) checks the identity of the user/applicant.
- Generation/issue of the certificates: the Certificate Authority (CA) issues the certificate. This certificate contains information on the holder, the issuer, the permitted use and its lifespan (valid from and valid until).
- Suspension: the certificate is temporarily blocked. This is not practiced at SwissSign.
- Revocation/invalidity: the certificate is revoked or declared invalid before expiry.
- End of certificate validity: the certificate has expired.
- Certificate renewal: renewal of the certificate.
The Time Stamping Authority (TSA) is the service of a CA which gives certification provided with the date, time and a signature of the CA and according to which certain digital data existed at a specific time. The SwissSign Time Stamping Authority corresponds with Swiss legislation (ZertES).
Like in the physical world, it is also dangerous in the digital world if someone loses a key or the key is no longer valid, e.g. because of the departure of an employee. Keys/certificates are therefore repeatedly registered which have to be blocked in order to prevent damage. SwissSign publishes – like every CA – these keys/certificates in so-called “Certificate Revocation Lists” (CRLs).
The CRL contains all serial numbers of the certificates which were declared invalid before the expiry of their certificate lifespan. In the certificate status check the list is loaded from a public URL and the serial number of the certificate which needs to be checked is looked for in this list: if it is present, the certificate is blocked, otherwise it is valid.
Revoked certificates or certificates declared invalid also remain on the CRL after the expiry date indicated in the certificate. The reason is that for the validation of the signature it is important to know when a certificate was revoked.
As a rule CRLs are updated at regular intervals. As with the certificates, with the CRLs the lifespan is also specified in the CRL itself. This lifespan is much longer than would be assumed from the issue frequency (at least twice a day). This means «fault majeur» is also covered. CRLs can be stored locally on an intermediate basis and enable a certificate status to be queried offline. Here the connection between certificate holder and the relying party is not disclosed to the CSP. There is a relatively high level of inaccuracy when querying the status of a certificate, however.
One alternative is the validation service OCSP (Online Certificate Status Protocol) which works online. In real time this gives information on the validity of a certificate. For OCSP use the high performance of the CA is important. The SwissSign CA ensures this high performance and also uses only its own software developed in Switzerland for OCSP. Online status checks are usually used where it is important to check the precise time of the certificate, e.g. with financial transfers.
Google Chrome is based on the model of “Certificate Transparency” (CT). Based on the CT security it will be easier to detect and identify faults made by Certificate Authorities and to eliminate insecure web sites. This process pushed by Google Chrome is an important support of trustful internet communication.
Basic idea: by use of secure logging all certificates for secure internet communication should be registered. At least 3 different log servers should be used. Fraudulent certificates, manipulations, illegal registrations, not-allowed additions should be detected by the internet community. A certificate could be easily revoked and would be excluded from any communication by browser.
BLUE SSL EV certificates powered by Swisssign are registered in at least 3 certificate transparency logs. Every user of a EV certificate can benefit from the logging and will see a green bar in the Google Chrome browser if OCSP stapling is enabled. SwissSign registers the certificate also at a Pan-European certificate transparency log together with other European certificate authorities.
Basic information: e-mails are encrypted with the public key of the recipient and decrypted with the private key of the recipient. Signing is done with the certificate.
- Certificates or the password for the private key can be lost. The e-mails encrypted with this certificate can no longer be read by anyone.
- Certificates are renewed but it is forgotten to also install the expired old certificate. All old stored e-mails can no longer be read.
- An employee leaves the company or is absent for a considerable time. His e-mails can no longer be read by anyone else.
- A virus or Trojan is sent with an encrypted e-mail. No antivirus program can search through an encrypted e-mail, the virus or Trojan can infiltrate with impunity. This means that encryption can even mean a security risk in this case.
- The customers themselves are always responsible for the installation of the certificates on their mail client. Not all users have the necessary experience for installing these certificates.
http + Secure Socket Layer SSL = https
https is the standard for the encrypted transfer of data between browser and web server – for secure web transactions. It is based on X.509 certificates. An asymmetric encryption procedure is used here. This requires a lot of mathematical work and causes high processor utilization. Therefore the transferred keys cannot be intercepted by an attacker.
This is how it works (establishment of the HTTPS connection): the web server sends the browser its digital certificate signed by a CA (web server certificate). On the one hand this contains the public key of the web server, and on the other hand it identifies the server. The browser checks this is authentic with the help of the installed CA certificate – the browser trusts correctly signed web server certificates. The browser now generates a secret symmetric key which is used only for this SSL session, encrypts it with the public key of the web server and sends this to the web server. Other data can now be encrypted with this session key. Symmetric data encryption can now begin with the secret session key now available on both sides. This is clearly easier and causes only low processor utilization.
Role of the CA: this guarantees the unaltered transfer of the public keys and the authenticity of the web server. The certificate of the CA is installed in all browsers and appears there as a «trusted root certification authority». If the certificate is not installed, the user receives an error message when opening the website. The web server also generates a key pair whose public part is transferred to the CA. The CA checks the data of the web server operator and signs the key. The thus created web server certificate guarantees the authenticity of the web server and represents a guarantee for users that they have connected with the right web server.
For Outlook Web Access (OWA) you need a SSL certificate that is installed on the OWA server. Depending on which level of trust you want, select between an individual BLUE SSL Certificate DV, OV and EV
Our Techno Partner SwissSign CA trust center has to meet very high requirements so that certificates are considered sufficiently secure. A key aspect for security is the key length, which is repeatedly adapted on account of progress made in computer science and cryptology.
Since 2010 the industry standards have recommended a key length of 2048 bits for asymmetric certificate keys. Symmetric keys can then be exchanged with these asymmetric keys and contents encrypted symmetrically.
The SSL certificate with its asymmetric keys is used only for the unique and secure identification of the server, for mutual authentication and also for setting up the secure channel for exchanging symmetric keys. For performance reasons the data exchange itself is then only via the exchanged symmetric keys. All BlueCerts SSL certificates powered by SwissSign allow the highest possible key length of the symmetric keys, which today are typically 256 bits
The creation and issuance of certificates is performed based on the standard RFC5280. The new standard foresees the placement of the email address in the Subject Distinguished Name as well as in the Subject Alternative Name (SAN). In special the mail applications will analyze the entry in the SAN field. The placement of the email address in the special email address attribute of the Subject Distinguished Name was only done in legacy implementations and is no longer supported by SwissSign.
Every time a website is opened in the web browser, this generally means that a URL of a so-called OCSP responder is entered which indicates whether the certificate of the website is still valid or has been blocked.
This action initially slows down the loading speed of the website, depending on the speed with which the response comes from the OCSP responder. Secondly, the operator of an OCSP responder also receives information about which website was viewed from which IP address, even if SwissSign does not use and save this information.
To avoid this problem, OCSP stapling was introduced a while ago. Here the web server regularly – for example every hour – receives a response from the OCSP responder about its own certificate and then uses this signed validity statement so that the user’s web browser knows that the certificate is still valid.
In the case of Certificate Transparency, there are essentially two possibilities of processing the log information:
- The signatures of the log servers are included in the certificate.
- The OCSP responder mechanism is used to confirm the entry in the log server as well as the validity.
It is also possible, but requires a lot of work, for the customers themselves to register their certificates with three logs and include their signatures in the web server.
The integration of the signatures (in particular with three signatures) expands the certificate more and more and additionally leads to operations slowing down, which can also be a disadvantage in particular in the Internet of Things environment with small computing capacities. OCSP stapling is also the ideal solution here.
By the way Firefox and Chrome will require OCSP Stapling in their 2016 versions soon.
Published in 2013, Certification Authority Authorization (CAA) is an Internet standard with the designation RFC 6844.
Adopting a similar structure to a large phone book, domain names are listed in a globally distributed register of names, the so-called Domain Name Service (DNS). A website with a recognisable name like www.swisssign.com is translated by this service into an Internet address such as “46.175.9.80”, meaning that it can be accessed by various Internet services (e.g. a browser). In addition to this function, the Domain Name Service also allows for the provision of additional information, such as the name and address of a website’s owner.
Thanks to the CAA standard, further information is now saved for these domains: It is recorded which certification authority is permitted to issue a certificate for the named domain. If no certification authority is recorded, any certification authority can issue a certificate. Otherwise, a certification authority cannot issue a certificate for the domain if its name is not stated here.
Why has this rule been applied?
In recent years, there has been an increasing number of “man-in-the-middle” attacks, a means of attack that is also used by secret services around the world. In order to enable them to spy on who is accessing an encrypted website, they ask an allied or compliant certification authority to issue an identical certificate for the website in question. Using this “fake” certificate, the website is then reconstructed by the attacker, with the data traffic initially being directed to the fake website by means of router manipulation. The details are then listened into and the communication is forwarded directly to the original website. In most cases, the website subjected to the attack and its visitors are none the wiser.
A CAA entry can reduce this risk by allowing for the deliberate recording of trusted certification authorities. Since September 2017, all certification authorities permitted in the browsers have been required by the CA/Browser Forum, an association of browser producers and certification authorities, to check the CAA entry prior to issuing a certificate.
CAA is a process whereby the domain owner can determine which CA is allowed to issue certificates for its domain. A so-called CAA record is entered in the DNS. From September 2017, SwissSign will check all domains before issuing certificates to determine whether you have a restriction in your CAA record. Domains that have been restricted to accept certificates from certification authorities other than SwissSign are not allowed in the certificate. The certificate application is rejected. If no restriction has been placed or the CAA record names SwissSign as CA, the certificate will be authorized.
The CAA configurator supports you in defining the exact parameters for your web site.
Here are some examples depending on the DNS technology used:
Permission for SwissSign to issue certificates
Standard BIND Zone File
For BIND ≥9.9.6, PowerDNS ≥4.0.0, NSD ≥4.0.1, Knot DNS ≥2.2.0
example.com. IN CAA 0 issue “swisssign.com”
Legacy Zone File (RFC 3597 Syntax)
For BIND <9.9.6, NSD <4.0.1
example.com. IN TYPE257 \# 20 0005697373756573776973737369676E2E636F6D
Permission for SwissSign to issue non-wildcard certificates
Standard BIND Zone File
For BIND ≥9.9.6, PowerDNS ≥4.0.0, NSD ≥4.0.1, Knot DNS ≥2.2.0
example.com. IN CAA 0 issue “swisssign.com”
example.com. IN CAA 0 issuewild “;”
Legacy Zone File (RFC 3597 Syntax)
For BIND <9.9.6, NSD <4.0.1
example.com. IN TYPE257 \# 20 0005697373756573776973737369676E2E636F6D
example.com. IN TYPE257 \# 12 0009697373756577696C643B
Permission for SwissSign to issue only wildcard certificates
Standard BIND Zone File
For BIND ≥9.9.6, PowerDNS ≥4.0.0, NSD ≥4.0.1, Knot DNS ≥2.2.0
example.com. IN CAA 0 issue “;”
example.com. IN CAA 0 issuewild “swisssign.com”
Legacy Zone File (RFC 3597 Syntax)
For BIND <9.9.6, NSD <4.0.1
example.com. IN TYPE257 \# 8 000569737375653B
example.com. IN TYPE257 \# 24 0009697373756577696C6473776973737369676E2E636F6D
Unfortunately no. Since according to www.whois.ch you are not the owner of the domain dyndns.ch or dyndns.org and DynDNS does not carry out any domain validation, it is difficult to receive confirmation of the owner that can also be checked.
Standard SSL certificates are suitable only for securing individual domains or sub-domains. So in the case of UCC a different SSL certificate would have to be obtained and installed for each server, and this would require a lot of work.
The UCC/SAN certificate contains an extension as a special SSL certificate which allows several so-called “Subject Alternative Names” (SANs). These SANs may consist of prefixes (sub-domains) and host names. The UCC/SAN certificate therefore enables several SANs to be secured with a single certificate. The entire communication between several servers is therefore encrypted with just one single UCC/SAN certificate. The complexity with the server configuration is drastically reduced in this way.
If you install a UCC/SAN environment with MS Exchange there is always the question if you could choose for a (cheaper) wildcard certificate or if you opt for a (more expensive) Multidomain certificate. In earlier times CAs offered a special UCC/SAN certificate which allowed also internal domain names or even internal IP addresses. This type of certificate is no longer allowed.
Generally we recommend SSL Multidomain certificates for Microsoft UCC/SAN environments. Starting with Microsoft Exchange 2010 also wildcard certificates are allowed. They are also defined in Microsoft Technet. But please note that these certificates can not be used in older (<= 2007) versions or in combination with older mobile phones like Windows Mobile 5.0.
This web page gives you some good hints for the usage of wildcard certificates. Concerning Lync you will find good hints here and in special concerning the usage of wildcard certificates here.
SSL certificates are offered in three different packages:
- Single-Domain: usable only for a special website. Example: mywebsite.com.
- Multi-Domain: usable for multiple websites/domains. Example: mywebsite.com, yourwebsite.com, hiswebsite.ch.
- Wildcard: usable for any website with a specified domain name. Example: db.mywebsite.com, mail.mywebsite.com, sap.mywebsite.com etc.
Multi-Domain certificates are often called UCC/SAN certificates (Unified Communication Certificates / Subject Alternative Name) since they perfectly fit in a Microsoft Exchange or Lync environment. The SAN field of a certificate contains the further domains of a Multi-Domain certificate or the Wildcard entry of a Wildcard certificate.
Very often Multi-Domain or Wildcard certificates are chosen because they are cheaper than multiple single certificates. Copies of the same BlueCerts certificates powered by SwissSign can be used on an arbitrary number of servers. By this it would be possible to secure the complete server and device farm of a company. Thus Wildcard certificates are very convenient but their use is also risky in large IT environments: If a private key is compromised or stolen on one of those many servers and be used to build up a fake additional website as man-in-the middle system it would nearly be recognized and the damage is huge since this site has also a perfect certificate based on your company name. This is also the reason why EV Wildcard certificates are not allowed.
With Multi-Domain certificates you do not have this problem. A drawback of a Multi-Domain certificate could be the performance in operation if it was filled up with a long list of domain names. In order to communicate securely servers have to exchange the certificate. If this certificate contains a long list, more bytes must be transmitted. This will not influence the performance in case 20 domains are used but 50, 100 or 200 SAN entries could sometimes end up in a performance issue.
Due to the many domain entries Multi-Domain certificates are very often updated or exchanged, if they contain a lot of SAN entries. Sometimes domains do not belong to the certificate owner and the owner of the website has to authorize the usage. If this domain cannot be used any longer, the certificate must be exchanged – on all systems.
Exactly the same happened in 2014 with the heartbleed bug detected only in OpenSSL software packages of the newer generation. All Wildcard or Multi-Domain certificates had to be renewed, also on all other websites protected by the certificate even if they were not a target of the heartbleed bug. Each change of certificate results in a downtime of the system. Also in case of end of the validity period you have to exchange the certificate on all systems and this must be planned in time before.
It is part of each decision to compare tradeoffs with risks. In small environments with sufficient control and in special for use with Microsoft UCC the usage of these certificates make good sense. Please have also a look to our special FAQ “UCC/SAN – Wildcard or Multi-Domain certificates for Microsoft Exchange?” in case you want to know which certificate you should use for a Microsoft Exchange environment.
No, unfortunately this is not allowed according to RFC 2818:
“Matching is performed using the matching rules specified by RFC 2459. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com”
We therefore recommend purchasing two wildcard certificates: one for *.mydomain.com and one for *.sub2.mydomain.com. With BlueCerts wildcard certificates powered by SwissSign it is also not possible to indicate different Subject Alternative Names (SANs).
Per e-mail address. As an individual you can obtain various certificates with different e-mail addresses in each case.
Published in 2013, Certification Authority Authorization (CAA) is an Internet standard with the designation RFC 6844.
Adopting a similar structure to a large phone book, domain names are listed in a globally distributed register of names, the so-called Domain Name Service (DNS). A website with a recognisable name like www.swisssign.com is translated by this service into an Internet address such as “46.175.9.80”, meaning that it can be accessed by various Internet services (e.g. a browser). In addition to this function, the Domain Name Service also allows for the provision of additional information, such as the name and address of a website’s owner.
Thanks to the CAA standard, further information is now saved for these domains: It is recorded which certification authority is permitted to issue a certificate for the named domain. If no certification authority is recorded, any certification authority can issue a certificate. Otherwise, a certification authority cannot issue a certificate for the domain if its name is not stated here.
Why has this rule been applied?
In recent years, there has been an increasing number of “man-in-the-middle” attacks, a means of attack that is also used by secret services around the world. In order to enable them to spy on who is accessing an encrypted website, they ask an allied or compliant certification authority to issue an identical certificate for the website in question. Using this “fake” certificate, the website is then reconstructed by the attacker, with the data traffic initially being directed to the fake website by means of router manipulation. The details are then listened into and the communication is forwarded directly to the original website. In most cases, the website subjected to the attack and its visitors are none the wiser.
A CAA entry can reduce this risk by allowing for the deliberate recording of trusted certification authorities. Since September 2017, all certification authorities permitted in the browsers have been required by the CA/Browser Forum, an association of browser producers and certification authorities, to check the CAA entry prior to issuing a certificate.
Principally you can request a BLUE E-MAIL Certificate w/o Pro option for a team account. In each case a person must be nominated who is responsible for the keys of this group or functional account.
Please follow the regulations of the CP/CPS:
- If you bought the certificate in the webshop you should use the identifier “pseudo:” instead of the first and last name, e.g. pseudo: Sales Team.
- Email validated BLUE E-MAIL Certificates can also be used for team accounts as long the mail address is validated as existing mail address.
CAA is a process whereby the domain owner can determine which CA is allowed to issue certificates for its domain. A so-called CAA record is entered in the DNS. From September 2017, SwissSign will check all domains before issuing certificates to determine whether you have a restriction in your CAA record. Domains that have been restricted to accept certificates from certification authorities other than SwissSign are not allowed in the certificate. The certificate application is rejected. If no restriction has been placed or the CAA record names SwissSign as CA, the certificate will be authorized.
The CAA configurator supports you in defining the exact parameters for your web site.
Here are some examples depending on the DNS technology used:
Permission for SwissSign to issue certificates
Standard BIND Zone File
For BIND ≥9.9.6, PowerDNS ≥4.0.0, NSD ≥4.0.1, Knot DNS ≥2.2.0
example.com. IN CAA 0 issue “swisssign.com”
Legacy Zone File (RFC 3597 Syntax)
For BIND <9.9.6, NSD <4.0.1
example.com. IN TYPE257 \# 20 0005697373756573776973737369676E2E636F6D
Permission for SwissSign to issue non-wildcard certificates
Standard BIND Zone File
For BIND ≥9.9.6, PowerDNS ≥4.0.0, NSD ≥4.0.1, Knot DNS ≥2.2.0
example.com. IN CAA 0 issue “swisssign.com”
example.com. IN CAA 0 issuewild “;”
Legacy Zone File (RFC 3597 Syntax)
For BIND <9.9.6, NSD <4.0.1
example.com. IN TYPE257 \# 20 0005697373756573776973737369676E2E636F6D
example.com. IN TYPE257 \# 12 0009697373756577696C643B
Permission for SwissSign to issue only wildcard certificates
Standard BIND Zone File
For BIND ≥9.9.6, PowerDNS ≥4.0.0, NSD ≥4.0.1, Knot DNS ≥2.2.0
example.com. IN CAA 0 issue “;”
example.com. IN CAA 0 issuewild “swisssign.com”
Legacy Zone File (RFC 3597 Syntax)
For BIND <9.9.6, NSD <4.0.1
example.com. IN TYPE257 \# 8 000569737375653B
example.com. IN TYPE257 \# 24 0009697373756577696C6473776973737369676E2E636F6D
Due to the adaptation of the TSA service to the new requirements of eIDAS and ZertES the resulting signature to the Adobe client is now several bytes longer than before. Adobe is not prepared to handle this. Therefore Adobe gives the hint to increase the size of the iSize value in the registry. For this please find the following example fix for Adobe Acrobat DC. We recommend to save the registry file properly before any change. Note: registry file is specific to Adobe Version and must be modified appropriately.
Copy and save text below as “fix_adobe.reg” and double-click to apply fix:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Adobe\Acrobat Reader\DC\Security\cASPKI\cAdobe_TSPProvider]“iSize”=dword:00002800
Time stamps can be used as part of workflow and archiving solutions. Although every electronic signature already contains a time indication (local system time), it can be useful to connect a time certified from an external source with the data and documents. In particular as part of solutions to implement legal requirements such as the company accounts decree GeBüV, compliance rules such as SOX, Basel II or sector-specific quality frameworks like GMP. This means that it can be proven easily and indisputably at any time that the corresponding data set existed at a specific time and has not been changed since (integrity).
Technically the time stamp is a signature of the CA which contains a trusted time. The creation of this time stamp takes place via the Time Stamping Authority (TSA) according to RFC 3161. The protocol RFC 3161 defines that the query contains the hash value and this is then signed by the TSA. This ensures that the TSA service does not find out anything about the contents of the time stamped documents.
There are two possibilities:
- By use of a suitable HSM (hardware security module) or a comparable device you can build up your own time stamping service. We can recommend you an apropriate partner solution if you like. In this case you will buy a timestamp certificate.
- You can use our powerful time stamping service directly by use of the RFC 3161 interface. Up to 20 signatures are free per day. For more signatures you can request an offer.
To use the BlueCerts Time Stamping Service powered by SwissSign you need a digital certificate. With this you can then sign a PDF document and provide it with the BlueCerts time stamp powered by SwissSign. After the signature you can check the time stamp in the document by clicking on the signature and selecting “Signature Properties” and “Date/Time”.
On request the BlueCerts Time Stamping Service powered by SwissSign can also be adapted according to your wishes. Please contact us for this.