Below are the most recent manuals for the use or installation of our products. Are you looking for a specific manual that's not listed? Please contact us for more information and assistance.
In order to use two-factor authentication on your Networking4all account, you need an application that can generate two-factor authentication codes. The app 'Google Authenticator' (for Android and for Iphone)can be installed on your mobile phone for this purpose. Follow the steps on your phone to install the app. Keep your mobile phone nearby for the following steps.
Log into the Networking4all portal. Go to the menu 'My Account' and click on the menu-option 'My Account'. Click on the tab 'Account' and scroll down to find the account option 'Two-factor authentication'.
Open the app you previously installed on your phone and press the red plus-icon. Choose the option 'Scan a barcode'. Your phone will now start up your camera: a red square will appear on your screen. Scan the QR code on your account page, making sure the entire code falls within the red square.
Switch the option 'Two-factor authentication' to 'active' and click Save.
From this moment, any time you log in to the Networking4all portal, you will first be shown the login screen where you enter your username and password. After entering your credentials, you will be asked to enter a code. Open the app on your phone. Google Authenticator automatically generates a new code for you every so often. Enter the code belonging to your Networking4all account in the field on the login screen.
The common name is the hostname for which an SSL certificate is issued. This can vary between types of certificate. Most commonly, the common name is the entire hostname, such as 'www.yourdomainname.com'. In the case of a wildcard, however, the common name is '*.yourdomainname.com'. For non-web applications of the SSL protocol, such as email certificates, the common name is usually the full email address.
When you purchase a certificate from Networking4all, you can also count on our support and advice. This means that we actively monitor the expiration date of your certificate, and whether it is still installed properly and safely. We also keep you informed on important security updates.
While a Let's Encrypt certificate might be free, it does not come with the extensive service and support Networking4all has to offer. For instance, a Let's Encrypt certificate is only valid for 3 months, and you are entirely responsible for the timely renewal of your certificate.
SSL is based on the encryption of data using a private and a public key.
A private key is created by converting a string of automatically generated text to a key file with the use of a mathematical algorithm, giving it a unique value. This private key file is then used to generate a Certificate Signing Request (CSR), which in turn can be used to create an SSL certificate. During the CSR process, a public key is generated. The private key must remain secret at all times. The private key is used in the encryption process of certificate-signed data, and decryption of encrypted data.
The public key is generated during the CSR creation process and can be distributed publicly. A public key is used to encrypt information that is only intended for the owner of the private key. The combination of the private and public key can then be used to decrypt the information. A public key can also be used to verify the sender of a message as the owner of the private key.
The strength of the encryption of a certificate is largely inherent to the encryption algorithm that was used to generate the private key. Hackers are intent on breaking these encryption algorithms: if the algorithm is out in the open, it can be combined with a public key to find the corresponding private key. Until recently, the RSA algorithm was most commonly used, but the ECC or Elliptic Curve Cryptography algorithm is quickly growing in popularity. This algorithm can create a much smaller key while not losing any strength when compared to the much larger RSA keys. For instance, an ECC key of 228 bits is just as safe as an RSA key of 2380 bits. More and more Certificate Authorities are therefore moving away from RSA in favour of ECC.
A wildcard certificate can secure multiple subdomains under one unique domain name. A wildcard certificate can be recognised by the use of an asterisk, such as *.networking4all.com. This protects multiple underlying services, such as sip.networking4all.com or webmail.networking4all.com. It is also possible to install a wildcard certificate on multiple servers.
When ordering a wildcard certificate, it is important to keep subdomain levels in mind. This means that a wildcard certificate for *.networking4all.com will secure test.networking4all.com, but cannot work for test.webmail.networking4all.com. That requires a separate wildcard certificate.
Wildcard certificates are only available as domain validated (DV) or organisation validated (OV) certificates. It is not possible to order a wildcard EV certificate.
A Wildcard SAN certificate offers the same functionalities as a regular wildcard certificate, but also allows the use of wildcards in the SAN names. The following example explains this:
The Wildcard SAN certificate is only available as an OV certificate. This type of SAN certificate has space for up to 100 SAN names.
Unlike regular certificates, the wildcard SAN does not automatically include the domain name with www. If the domain name with www needs to be secured as well, it has to be added to the certificate as a separate SAN name. The common name is exempt from this rule: it is supported both with and without leading www.
Wildcard certificates and Wildcard SAN certificates can be requested through our SSL wizard.
The intermediate certificate is a certificate that was issued as a dividing layer between the Certificate Authority and the end users certificate. It serves as a verification device that tells a browser that a certificate was issued on a safe, valid source, the CAs root certificate. These root certificates are part of the browsers by default.
The intermediate certificate is issued along with every SSL certificate order, and needs to be installed on the server at the same time. By using the fingerprint of the intermediate certificate that is part of the end users certificate, a browser can check whether the certificate was issued on a valid root certificate.
It may occur that an end user certificate was issued on a chain of multiple intermediate certificates. In that case, all appropriate intermediate certificates must be installed on the server. Only then will the browser be able to retrace the string of fingerprints and certificates to the root certificate in the browser.
The root certificate is the starting point of a chain of trust upon which an SSL certificate is issued. The root certificate belongs to the Certificate Authority. The root certificate is used to issue intermediate certificates, that in term make it possible to register SSL certificates for end users. These certificates inherit the trust level from the root certificate.
Each browser or service that makes use of SSL certificates contains a list of approved root certificates. Whenever a website is visited over an SSL connection, the validity of the certificate is checked by verifying the fingerprints of the certificate and the accompanying intermediate certificate, until the fingerprint of the root has been reached. This is then checked against the root certificate in the browser. If these do not match, the certificate will not be valid.
SNI stands for Server Name Indication. SNI is an additional protocol to the SSL/TLS protocol that was developed as a solution to the problem of the diminishing supply of IPv4 addresses. By including the hostname with which the client wishes to set up a connection during the handshake process, a server can host multiple HTTPS-protected websites, each with their own SSL certificate, on the same IP address and TCP port number.
In order to use the SNI protocol, the SSL/TLS library must support SNI. The SNI protocol has been supported by the OpenSSL library since 2004, but since this library can be used on both a browser- and OS- level, some browsers have decided to not support SNI on every OS. This is mostly older software.
The following browsers or browser/OS combinations do not support SNI:
The IBM HTTP server also does not offer support for SNI.
DANE is a security protocol that goes beyond the standard HTTPS protocol in securing the trust chain between server, Certificate Authority, and user.
In the current HTTPS protocol it is assumed that certificates issued by a trusted CA are automatically also trusted and secure. The root certificate of the CA is used as a so-called trust anchor. However, this means that if a trusted CA is hacked, browsers wont be able to differentiate between real and falsely issued certificates.
DNSSEC was created to uplift the security of domains. This protocol means that a separate certificate is created for the nameserver of a domain. A summary of this public certificate is then handed over to the registry handling the TLD. Any time a browser sends a request, the registry responds with not only the nameserver data, but also the signature belonging to the certificate. When this signature does not correspond with the information on the nameserver, or is missing from the response, the DNS data is invalid.
DANE is a protocol that only works when DNSSEC is activated. DANE lets the browser check the TLSA record for a public fingerprint of a certificate that the user has marked as safe. This could be the intermediate certificate of the CA that issued the certificate on the server, but could also be the fingerprint of the certificate itself.
Creating a TLSA record can easily be done online with the help of a generator such as the TLSA Generator on SSL-tools.net.
Cipher Suites are an important part of the server configuration. They are pre-set combinations of different algorithms used in the encrypted traffic between server and user. The following parts are combined to define a cipher suite:
Each separate connection between the server and the user of a website is preceded by a handshake. During this handshake, the user tries to contact the server using a ClientHello and a ServerHello, and allows the exchange of information about the cipher suites that the client and the server are familiar with. The server uses this list of cipher suites to find the most suitable cipher suite, and uses the protocols contained in it to encrypt all further communications between the server and the client.
How a cipher suite is constructed is the most important factor for a server in deciding which cipher suite to use. While the personal preference of the owner of the server plays a large role in which cipher suites are installed on a server, cipher suites using ECDHE are preferred over all others. This protocol uses the almost unbreakable ECC algorithm.
Other than that, the type of cryptographic protocol used plays a large part. Nowadays, TLS 1.2 is the norm. Its predecessors, SSL 2.0 and 3.0, are seen as unsafe due to their weaknesses that allowed Man in the Middle attacks to succeed. For example, the handshake in SSL 2.0 was unsecure, allowing a hacker to force the use of a weaker cipher suite.
The administrator of a website can enforce the use of the best possible cipher suites by regularly updating the software and using proper configuration. A webserver uses webserver software, such as Apache or NginX, which in turn use software known as libraries, such as OpenSSL. This contains all known cipher suites. It is therefore important to keep this library up to date, because a cipher suite must be saved in the library if the server software wants to be able to use it.
A Certificate Authority Authorisation Record (CAA) is used to determine which Certificate Authorities (CAs) are authorised to issue certificates for a certain domain. Such a record prevents other CAs from issuing certificates for that domain. By setting up a CAA record, the owner of a domain can also be notified whenever anyone illegally attempts to have a certificate issued for their domain.
CAA records can be set up for the entire domain, or specific host names. They are transferrable to subdomains, unless a separate record is set up on the subdomain to overwrite the main record. CAA record can be used on both single-domain and wildcard domains.
A CA must check for the existence of a CAA record
Setting up a CAA record is not obligatory for the end user. However, it is highly recommended to do so as an extra security measure. As of 8 September 2017, it becomes mandatory for a CA to check the CA record. When a domain has at least one CAA record available and the CA trying to request a certificate is not included, that CA cannot issue a certificate for this domain. The check for the existence of a CAA record occurs during the request process for the SSL certificate. When you edit or add a CAA record to the domain at a later time, any SSL certificate requested before the edit will still be valid.
Check a CAA record
You can check for the existence of a CAA record and the values of a record using the Networking4all Qualys SSLLABS scan.
Setting up a CAA record
The setup of a CAA record works with a set format. It uses three different tags:
One of these tags must always be used when creating a CAA record. An example of a CAA record is:
Additional CAA policy
It is possible to add an additional CAA policy to a domain name. This can include, for example, the rule that only EV SSL certificates may be issued for this specific domain or host name. For example:
CAA record per CA
Below are the records examples per CA to setup your CAA policy:
OCSP stands for Online Certificate Status Protocol. This is a browser protocol that checks the validity of an SSL certificate with the help of a whitelist.
The validity of an SSL certificate is commonly checked with the use of a Certificate Revocation List: a blacklist issued by the Certificate Authority listing all the revoked certificates. Each time a website with a certificate is visited, the browser sends a request to the CA, upon which the CA returns the CRL. The browser can then check whether the certificate is listed on the blacklist. If this is the case, the browser can show an error message to the user.
Using a CRL comes with its downsides: the browser has to send a request for the CRL with every visit, which creates more traffic to the CA, especially when the website is popular. This can potentially generate such an amount of traffic that it can be used for a DDoS attack. If the CA is unavailable for a response, the browser wont have a CRL with which to check the certificate. It could even erroneously assume that the certificate is valid. It is therefore also very important that the CA keeps the CRL up to date.
OCSP was created as an alternative to the CRL, and works with a whitelist instead of a blacklist. Instead of having to request the full blacklist from the CA, the browser can now simply send the certificate that needs to be checked for validity. The CA responds with the status of the certificate, and the browser can use this response to act accordingly. This method produces less traffic to the CA, and requires less actions from the browser, because it only has to process a small response status. Should the CA be unavailable to respond to the browsers request, the browser wont automatically send the user to the website: it will show an error message instead.
But OCSP has some drawbacks as well: while the chance may be reduced, it is still possible for the CA systems to overload. The request to the CA is also always made over HTTP, which leaves a possibility for hackers to eavesdrop. Finally, it is still questionable to include a third party in the validity check of a certificate, even if that party is the CA who issued the certificate in the first place.
In OCSP Stapling, it is not the browser, but the server hosting the SSL certificate that sends an OCSP request to the CA. This process is repeated regularly, keeping the result as up to date as possible. The server then connects the result to the SSL handshake, a process that is called upon each time a browser connects with the server. This offers multiple advantages: it requires less traffic between the server and the browser, because the response to the browsers request is immediately returned with the SSL handshake. The OCSP request to the CA from the server runs on a closed circuit, and the response from the CA must always be signed by the CA in order to be valid. This eliminates the possibility of abuse of this system. The result is always kept for a longer period of time, making it more stable than CRL or OCSP. Should the CA be unavailable, the server can still produce a valid result that can be used to verify the certificate. And when the server is unable to return this request to the browser, the browser can always perform a regular OCSP request.
OCSP Stapling is a setting in your webserver installation. The process of setting up this configuration depends on the software running on your server.
HTTP Strict Transport Security, or HSTS, is a response header that allows browser to be forced to use HTTPS for every subsequent request that it sends to a server. This means that when a user browses to http://www.networking4all.com, they will automatically be transferred to https://www.networking4all.com without the HTTP request being sent first. This also prevents hackers from forcing a downgrade attack during a Man in the Middle attack, which would force traffic over an unsafe connection instead of the encrypted HTTPS connection.
HSTS works in such a way, that not only direct traffic to the website is automatically transferred to a secure HTTPS connection: It also works for links on an external page that link to the HTTP-URL. The forced use of HTTPS also prevents the session key from being hijacked through cookies.
Setting up HSTS on a server is as simple as adding one response header to the config:
This ensures that the server enforces the use of HSTS for one year, or 31,536,000 seconds.
File approver is a kind of verification used in the issuance process of an SSL certificate. For file approver, a small file has to be placed on the server. The Certificate Authority can then verify the ownership using that approver file.
File approver can only be used in accordance with the API and is only available for the DV certificates of Symantec, Thawte, GeoTrust, and RapidSSL. This form of verification replaces verification by email.
The content of the approver file is sent to you in the API response. Copy this text and save it in a file with the name 'verify.txt'.
The approver file must be uploaded in the following directory on the server:
For more information on the use of file approver verification, please read chapter 5.3 of our API documentation.