The SSL Gold Certificate is used for the following reasons:
Since the organisation is validated, the company name in the certificate is transparently shown in webpages and applications.
The use of SSL Gold emphasises the importance a company places on building trust in the use of internet services.
On web pages sharing sensitive data or in webshops.
Revoked certificates are listed in so called certificate revocation lists. Or they will be published by the online service OCSP which validates online current validity of a certificate. Certificate revocation lists can be downloaded here:
Each SwissSign certificate is signed by a SwissSign intermediate certificate. The SwissSign intermediate certificate is again signed by a SwissSign root certificate. In order to have a trustful certificate it is necessary to install the complete certificate chain e.g. on a web server. All operation systems and browsers have included the SwissSign root certificate but the SwissSign intermediate certificate must be installed. Either it is possible to download the end certificate including the complete certificate chain on swisssign.net or the SwissSign intermediate certificate will be installed later.
Each SwissSign certificate is signed by a SwissSign intermediate certificate. The SwissSign intermediate certificate is again signed by a SwissSign root certificate. In order to have a trustful certificate it is necessary to install the complete certificate chain e.g. on a web server. All operation systems and browsers have included the SwissSign root certificate but in some special cases it might be necessary to install the root certificate. Either it is possible to download the end certificate including the complete certificate chain on swisssign.net or the SwissSign root certificate will be installed later.
In the login area you can download the “SwissSign seal” after the installation of your certificate and indicate your website is “secured by SwissSign”. This means that, in addition to the information in the browser, you also show that your website is secure and create trust among your customers.
With SwissSign SSL certificates you get unlimited server licenses. Unlike most other SSL certificates you can install your SwissSign SSL certificate on as many physical servers as you want!
Only SSL EV certificates issued from 1 January 2015 are affected. With these certificates the green address line of the browser (green bar) is missing with the Google Chrome browser from version 41. Only the https is shown in green with a green key. In the information on the certificate, the identity of the organisation which is running the website is still confirmed. But it is also indicated that there is no public entry.
Google Chrome is based on the model of „Certificate Transparency“ (CT). Based on the CT security it will be easier to detect and identify faults made by Certificate Authorities and to eliminate insecure web sites. This process pushed by Google Chrome is an important support of trustful internet communication.
Basic idea: by use of secure logging all certificates for secure internet communication should be registered. At least 3 different log servers should be used. Fraudulent certificates, manipulations, illegal registrations, not-allowed additions should be detected by the internet community. A certificate could be easily revoked and would be excluded from any communication by browser.
SwissSign EV certificates are registered in at least 3 certificate transparency logs. Every user of a EV certificate can benefit from the logging and will see a green bar in the Google Chrome browser if OCSP stapling is enabled. SwissSign registers the certificate also at a Pan-European certificate transparency log together with other European certificate authorities.
The issuance speed for SwissSign certificates depends on the certificate type and reaches from a few seconds up to 10 business days for certificates, which require an intensive manual verification of the requester, of the organization or of the domain. These deadlines are valid after reception of the registration documents by SwissSign and can be held under the exclusive condition that all documents are correct and complete.
An exception are those certificates with automated issuance, which do not require submission of documents (eg. domain-validated-only SSL). These certificates are usually issued immediately.
Issuance speed for SSL Certificates:
Issuance speed for Personal Certificates:
Issuance speed for Organization Certificates:
These deadlines are standard values and may be subject to extraordinary exceptions (eg. important workload of the registration authority)
The business identification number (UID) replaces the previous company number in the commercial register.
Since January 2011, the Federal Statistical Office (BFS) has allocated a unique business identification number (UID) with many areas of application for every economically active business in Switzerland. This enables the businesses to identify themselves with one and the same number for all contact with authorities.
The old eleven-digit commercial register number (CH-123.4.567.890-1) was replaced on 1 January 2014. Since this time, the UID has been the valid commercial register number.
In the SwissSign SSL Gold EV certificates there has been reference to the UID since this time.
Standard SSL certificates are suitable only for securing individual domains or sub-domains. So in the case of UCC a different SSL certificate would have to be obtained and installed for each server, and this would require a lot of work.
The UCC/SAN certificate contains an extension as a special SSL certificate which allows several so-called “Subject Alternative Names” (SANs). These SANs may consist of prefixes (sub-domains) and host names. The UCC/SAN certificate therefore enables several SANs to be secured with a single certificate. The entire communication between several servers is therefore encrypted with just one single UCC/SAN certificate. The complexity with the server configuration is drastically reduced in this way.
SwissSign registers all EV certificates in both certificate transparency logs of Google and additionally in the Pan-European certificate transparency log. Please note that you have to enable the “OCSP Stapling” feature on your web server. Starting in 2016 browsers like Chrome and Firefox will start to require “OCSP stapling” for certificate usage.
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.
SSL certificates are offered in three different packages:
Multi-Domain certificates are often called UCC/SAN certificates (Unified Communication Certificates / Subject Alternative Name) since they perfectly fit in a Microsoft Exchange or Lync environment. The SAN field of a certificate contains the further domains of a Multi-Domain certificate or the Wildcard entry of a Wildcard certificate.
Very often Multi-Domain or Wildcard certificates are chosen because they are cheaper than multiple single certificates. Copies of the same SwissSign certificate can be used on an arbitrary number of servers. By this it would be possible to secure the complete server and device farm of a company. Thus Wildcard certificates are very convenient but their use is also risky in large IT environments: If a private key is compromised or stolen on one of those many servers and be used to build up a fake additional website as man-in-the middle system it would nearly be recognized and the damage is huge since this site has also a perfect certificate based on your company name. This is also the reason why EV Wildcard certificates are not allowed.
With Multi-Domain certificates you do not have this problem. A drawback of a Multi-Domain certificate could be the performance in operation if it was filled up with a long list of domain names. In order to communicate securely servers have to exchange the certificate. If this certificate contains a long list, more bytes must be transmitted. This will not influence the performance in case 20 domains are used but 50, 100 or 200 SAN entries could sometimes end up in a performance issue.
Due to the many domain entries Multi-Domain certificates are very often updated or exchanged, if they contain a lot of SAN entries. Sometimes domains do not belong to the certificate owner and the owner of the website has to authorize the usage. If this domain cannot be used any longer, the certificate must be exchanged – on all systems.
Exactly the same happened in 2014 with the heartbleed bug detected only in OpenSSL software packages of the newer generation. All Wildcard or Multi-Domain certificates had to be renewed, also on all other websites protected by the certificate even if they were not a target of the heartbleed bug. Each change of certificate results in a downtime of the system. Also in case of end of the validity period you have to exchange the certificate on all systems and this must be planned in time before.
It is part of each decision to compare tradeoffs with risks. In small environments with sufficient control and in special for use with Microsoft UCC the usage of these certificates make good sense. Please have also a look to our special FAQ "UCC/SAN - Wildcard or Multi-Domain certificates for Microsoft Exchange?" in case you want to know which certificate you should use for a Microsoft Exchange environment.
No, unfortunately this is not allowed according to RFC 2818:
“Matching is performed using the matching rules specified by RFC 2459. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com”
We therefore recommend purchasing two wildcard certificates: one for *.mydomain.com and one for *.sub2.mydomain.com. With SwissSign wildcard certificates it is also not possible to indicate different Subject Alternative Names (SANs).
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:
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.