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.
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.
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.