The EV (Extended Validation) SSL Certificate is used for the following reasons:
Provides the best possible protection against phishing and man-in-the-middle attacks.
For use wherever trust is the highest priority. No other SSL Certificate offers more trust when using internet and web applications.
Within e-commerce applications or web pages where credit cards or other sensitive data is used. In companies which like to associate their brands with security and trust.
In order to obtain a SSL Gold EV certificate you have to choose the right business category in your certificate request:
Please note the following for the serial number and fields for the jurisdiction of incorporation:
In case of a „Private Organization“ you shall enter your registry number as serial number. As far the jurisdiction of incorporation operates on a local level all three certificate fields (locality, province/state, country) should be filled in. In case a jurisdiction of incorporation or registration agency operates on province/state level you shall leave the locality entry empty. In case a jurisdiction of incorporation or registration agency operates on country level only the country field should be filled in.
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!
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.
In order to obtain an SSL Gold EV certificate, associations also have to indicate a register number.In Switzerland, like companies associations can apply for a business identification number (UID). This is not to be confused with the EU VAT ID (called EU-UID in German). Associations with an annual turnover of less than CHF 150,000 are exempt from VAT but receive a business identification number on request. This business identification number has to be entered in the certificate as a register number. German associations are entered in the register of associations as registered associations and can use this number.
The SwissSign Fulfillment Center can see the Swiss business identification number. If you have not restricted the visibility of your business identification number, your association data will suffice. Otherwise please give us a business identification number confirmation. Foreign associations please enclose a register extract for the confirmation.
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.
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).