The SSL Silver Certificate is used for the following reasons:
Simple encryption offers protection of digital communications with devices and web pages.
Digital usage can be trusted thanks to domain-validated session encryption.
Web pages with a need for basic protection, or which use encrypted logins, forms etc.
Domain verification for is ensured via an e-mail sent to one of the following addresses (freely selectable):
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.
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)
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!
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′).
MS Outlook Webmail (OWA) does not support any e-mail certificates according to our current knowledge.
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), host names and private IP addresses. 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.
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).