Manuels & Documents

Ci-dessous vous trouverez les derniers manuels d'utilisation et d'installation sur nos produits en anglais. Êtes-vous à la recherche d'un manuel qui n'est pas dans cette liste? Prenez contact avec nous et nous nous ferons un plaisir de vous apporter nos services.


Foire aux questions (FAQ)

  • Comment activer l'authentification à deux facteurs?

    Si vous utilisez l'authentification à deux facteurs sur le compte de Networking4all, vous avez besoin d'une application pour générer les codes d'authentification à deux facteurs. Vous pouvez installer l'application 'Google Authenticator' (pour Android et Iphone). Suivez les étapes sur votre portable pour installer l'application. Gardez votre portable à portée de main.

    Connectez-vous à votre compte du portail de Networking4all. Allez sur le menu 'Mon compte' et cliquez sur l'option de menu 'Mon données'. Allez sous l'onglet 'Compte'. En bas de la page vous trouverez l'option 'l'authentification à deux facteurs.'

    Ouvrez l'application que vous avez installé sur votre portable et appuyez sur le signe plus rouge. Choisissez l'option 'Scanner le code barre'. Le caméra de téléphone sera démarré; il apparaît à l'écran une case colorée en rouge. Scannez le code QR à la page de votre compte, assurez-vous que la carrée dans le carré rouge.

    Cliquez sur Activer l'authentification à deux facteurs et cliquez sur enregistrer.

    Connecter

    À partir de ce moment, si vous vous connectez sur le portail de Networking4all, il vous sera tout d'abord indiqué l'écran de connexion, où vous remplissez votre nom d'utilisateur et mot de passe. Après vous avez rempli les données, vous êtes invité à entrer le code de sécurité supplémentaire. Ouvrez l'application sur votre portable. Google Authenticator génère automatiquement un nouveau code après quelques secondes. Remplissez le code appartenant à votre compte de Networking4all.

  • Qu'est-ce qu'un nom commun?

    Le nom commun est le nom de votre hôte pour lequel un certificat SSL est destiné. Celui ci peut différer par type de certificat SSL. Dans plupart de cas un nom de commun existe le nom d'hôte complet, par exemple 'www.votrenomdedomaine.nl'. Cependant, dans le cas d'un wildcard, il est '*.votrenomdedomaine.nl'. En outre, il y a non-web applications de SSL pour lequel un nom commun est utilisé, comme certificats email. En ce cas, le nom commun est l'adresse email complète.

  • Qu'est-ce qu'est la différence de certificats Networking4all et Let's Encrypt?

    Si vous achetez un certificat de Networking4all, vous recevrez gratuit conseil et support. Ceci signifie que nous surveillons activement le date d'échéance et si votre certificat est correctement installé et en toute sécurité. Nous vous informons aussi sur importantes mises à jour de sécurité.

    Un certificat Let's Encrypt est gratuit, mais il n'y a pas d'avantages des services que Networking4all offre. Un certificat Let's Encrypt est valable 3 mois, et vous êtes responsable de renouvellement du certificat.

  • Qu'est-ce qu'une clé privée et une clé publique?

    SSL s'établit grâce au cryptographie par une clé privée et publique.

    Clé privée

    Une clé privée est créée par une pièce de texte génère automatiquement à l'aide d'un algorithme mathématique qui a ajouté une valeur unique. Ensuite, il y a générer un CSR avec ce fichier de clé pour créer un certificat SSL. Dans ce processus CSR le clé publique est aussi créée. La clé privée doit toujours être gardée secrète. Avec cette clé, données chiffrées peuvent être déchiffrées et messages qui sont signés avec un certificat, peuvent être chiffrés.

    Clé publique

    La clé publique est créée pendant la création de CSR et peut être distribué au public. Une clé publique peut être utilisé par exemple pour chiffrer l'information qui peut être reçu seulement par le propriétaire de la clé privée. Une combinaison d'une clé privée et publique peut déchiffrer ces données. Une clé publique peut être utilisée aussi pour vérifier que le message est envoyé par le propriétaire de la clé privée.

    Algorithme de chiffrement

    La puissance de cryptage d'un certificat, est en grande partie inhérentes à l'algorithme de chiffrement qui est utilisé pour générer la clé privée. Hackers ont l'intention d'attaquer l'algorithme de chiffrement: si l'algorithme est en plein air, il est possible de trouver la clé privée à l'aide de la clé publique. Jusqu'à récemment l'algorithme RSA était le plus utilisé algorithme, mais l'algorithme ECC ou la cryptographie de courbe elliptique a rapidement gagné en popularité. Cet algorithme peut créer une taille plus petite qu la clé RSA de sécurité équivalente. Un algorithme EEC 228 bit a une sécurité équivalente qu'un algorithme RSA 2300 bit. Plus des Autorités de certification change aux clés ECC.

  • Qu'est-ce qu'un Wildcard certificat?

    Un wildcard certificat peut protéger plusieurs sous-domaines sous un nom de domaine unique. Un wildcard certificat est reconnu par un astérisque, par exemple *.networking4all.com. Ceci protège plusieurs services, comme sip.networking4all.com ou webmail.networking4all.com. Il est aussi possible d'installer un wildcard certificat sur plusieurs serveurs.

    Lorsque vous achetez un wildcard certificat, il est important de tenir en compte les niveaux de sous-domaines. Ça veut dire qu'un wildcard pour *.networking4all.com peut protéger test.networking4all.com, mais ne peut pas protéger test.webmail.networking4all.com. Cela requiert un wildcard certificat individuel.

    Un wildcard certificat est seulement disponible comme un certificat domaine validé (DV) ou organisation validé (OV). Il n'est pas possible de commander un wildcard EV certificat.

    Wildcard SAN

    Un Wildcard SAN certificat donne le même possibilités qu'un wildcard certificat régulier, mais donne plusieurs possibilités pour wildcards dans le cadre des noms de SAN. L'exemple ci-dessous s'explique:

    • Nom Commun: www.networking4all.com
    • SAN1: dev.ssl.nu
    • SAN2: *.support.ssl.nu
    • SAN3: dev.ssl.be
    • SAN4: *.support.ssl.be

    Le Wildcard SAN certificat est disponible seulement comme OV certificat. Avec ce type SAN certificat vous avez maximal 100 noms SAN à votre disposition.

    Contrairement aux certificats réguliers, le wildcard SAN certificat n'inclut pas de nom de domaine avec www. S'il doit être protégé, il doit être ajouté au certificat comme un nom SAN separat. Ceci n'applique pas pour le nom commun: cet est exclu de ce règle, il est sans et avec www disponible.

    Demander

    Wildcard certificats et wildcard SAN certificats peuvent être demandés par le SSL wizard.

  • Qu'est-ce qu'est un certificat intermediate?

    Le certificat intermédiaire est un certificat dépensé comme une couche intermédiaire entre l'autorité de certification et le certificat d'utilisateur final. Il sert un outil de vérification au navigateur que le certificat est basé sur une source valable et sûr, le certificat racine de CA. Ces certificats racines sont partis par défaut dans les navigateurs.

    Le certificat intermédiaire est délivré avec chaque certificat commandé et est installé au même temps sur le serveur. À l'aide d'empreinte de certificat intermédiaire dans le certificat d'utilisateur final, le navigateur peut contrôler si le certificat est basé sur un certificat racine valide.

    Il est possible qu'un certificat d'utilisateur final est basé sur plusieurs certificats intermédiaires consécutifs. En ce cas tous les certificats intermédiaires deviennent installés sur le serveur. C'est la seule solution que le navigateur peut tracer la chaîne d'empreinte au certificat racine dans le navigateur.

  • Qu'est-ce qu'un certificat racine?

    Le certificat racine est le point de départ d'une chaîne de confiance d'émission de certificat SSL. Le certificat racine appartient l'autorité de certification. Les certificats intermédiaires sont émis à l'aide de certificat racine qui donne la possibilité pour enregistrer les certificats SSL d'utilisateurs finals. Ces certificats hérite le niveau de confiance par le certificat racine.

    Chaque navigateur ou service qui utilise certificats SSL contient une liste des certificats racines autorisés. Une visite d'un site web avec un liaison SSL, la validité d'un certificat est contrôlé par les empreints de certificat et des certificats intermédiaires, jusqu'à l'empreinte de certificat racine est atteint. Ces sont contrôlés au moyen du certificat racine dans le navigateur. Si les certificats ne correspond pas, le certificat n'est pas valide.

  • Qu'est-ce qu'un SNI et quand je l'ai besoin?

    SNI signifie serveur de nom indication. SNI est un protocol supplémentaire pour le SSL/TLS protocol qui est développé comme solution pour la diminution du nombre d'adresses IP libres sous IPv4. Indiquer avec quel nom d'hôte le client veut faire une liaison pendant la poignée de main, plusieurs sites web HTTPS protégés peuvent être hébergé avec leur propre SSL certificat sur le même serveur et le même adresse IP et numéro de port TCP.

    Pour utiliser le SNI, la bibliothèque du module SSL/TLS doivent se soutenir le protocole SNI. À partir du 2004 le protocole est soutenu par la bibliothèque OpenSSL, mais parce que cette bibliothèque peut être utilisée au niveau de logiciel et OS, il y a navigateurs qui ne soutien pas SNI au chaque OS. Ceci est applicable pour ancien logiciel.

    Les navigateurs suivants ou combinaisons de navigateurs/OS n'offrent pas soutien pour SNI:

    • Internet Explorer (toutes versions) sous Windows XP
    • Safari sous Windows XP
    • Navigateur BlackBerry
    • Windows Mobile jusqu'au 6.5
    • Navigateur Android sous Android 2.X

    Le serveur IBM HTTP n'offre pas soutien pour SNI.

  • Qu'est-ce qu'est DANE et DNSSEC?

    DANE est un protocole de sécurité que protéger la chaîne de confiance entre le serveur, l'autorité de certification, et utilisateur plus que le HTTPS protocole standard. Le HTTPS protocole actuel suppose automatiquement que les certificats émis par un CA connu est sécurisé. Le certificat racine de CA est utilisé comme un ancre de confiance. Cependant ceci signifie que quand un CA autorisé a été de victime de piratage, certificats faux peuvent être émis par navigateurs qui ne sont pas déclaré dangereux.

    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 won't be able to differentiate between real and falsely issued certificates.

    DNSSEC

    DNSSEC a été créé pour augmenter le niveau de la sécurité de domaines. Il y a fait un certificat separat pour le serveur de nom d'un domaine en ce protocole un certificat. Un résumé est déposé d'enregistrement en ce qui concerne. Chaque demande d'un navigateur ne donne pas seulement les données de serveur, mais aussi le nom la signature qui appartient le certificat. Si les signatures ne correspondent pas de nom de serveur ou manquent dans la réponse, la donnée de DNS n'est pas valable.

    DANE

    DANE est un protocole que marche seulement quand DNSSEC est actif. Dane laisse le navigateur vérifie le record TLSA. En ce record l'empreinte publique d'un certificat laquelle l'utilisateur a indiqué comme sécure est enregistré. Ceci peut être, par exemple, un certificat intermédiaire de CA qui a émis le certificat qu'est sur le serveur, mais il peut être l'empreinte de certificat.

    Générer un record TLSCA peut être fait facilement en ligne avec un générateur comme le Générateur TLSA sur SSL-tools.net.

  • Qu'est-ce que sont les suites cryptographiques?

    Une suite cryptographique est une importante partie de la configuration du serveur. Elle est une combinaison préréglée d'algorithme différente qu'est utilisé dans le trafic crypté entre le serveur et l'utilisateur. Les parts suivants définissent les suites de chiffrements:

    • L'algorithme d'échange de clé, il détermine si et comment l'authentification est fait pendant la poignée de main.
    • L'algorithme de chiffrement, il détermine comment le trafic est encodé.
    • Le code d'authentification de message, aussi connu comme le MAC, il détermine avec quel bloc de trafic est haché dans un message chiffré cryptographiquement.
    • Le PRF ou fonction pseudo-aléatoire, une fonction appelée salée qui fonctionne comme une clé cryptographique si le MAC veut chiffrer un bloc de trafic, aussi fonctionner comme une clé secrète avec laquelle le bloc peut être lu.

    La poignée de main

    Il y a une poignée de main pendant chaque liaison individuelle entre le serveur et un utilisateur d'un site web. Pendant cette poignée de main, l'utilisateur cherche contact avec le serveur au moyen d'un ClientHello et un ServeurHello, les deux échangent information sur la suite cryptographique connue. Le serveur détermine lequel est le plus pratique à l'aide d'une liste de suite cryptographique similaire, et utilise les protocoles comme décrit dans la suite cryptographique pour chiffrement du trafic.

    Diffie-Hellman

    La structure de la suite cryptographique a une grande importance pour déterminer l'option plus sécure de serveur. Quelle suite cryptographique est les plus sécures dépendent de choix personnelle de propriétaire de serveur, mais il y a une préférence de suite cryptographique qui utilisent ECDHE, un protocole qu'utilise l'algorithme ECC qu'est difficile à pirater.

    En plus, quel protocole cryptographique utilisé est important. Aujourd'hui TLS 1.2 est le norme. Les précédents, SSL 2.0 et 3.0 sont dangereux par les points faibles qui invitent attaques man-in-the-middle. Il y avait une poignée de main en SSL 2.0 que n'était pas sécurisée, que fait possible pour un hacker de choisir un cipher suite faible que normal.

    Configurer

    L'administrateur d'un site web peut utiliser les meilleures suite cryptographique par mises à jour régulières et les configurations appropriées. Un serveur web utilise un logiciel de serveur web, comme Apache ou nginx, qui utilise bibliothèques logiciel comme OpenSSL. En cela sont mentionnés toutes les suite cryptographique. Mises à jour régulières de OpenSSL sont très importantes, parce qu'une suite cryptographique a été enregistré dans la bibliothèque avant qu'il peut être utilisé par le logiciel serveur.

  • Qu'est-ce qu'un record CAA?

    Un record autorisation d'autorité de certification (CAA) est utilisé pour déterminer quel autorité de certifications (CAs) sont autorisés émettre certificats pour un domaine. Ceci peut prévenir que certificats pour un domaine sont émis par un autre CA. Grâce à l'installation d'un CAA le propriétaire du domaine peut être informé des tentatives illégales d'obtenir un certificat sur le domaine.

    CAA records peuvent être utilisés pour tout le domaine, ou noms d'hôtes spécifiques. Ils sont transférable aux sous-domaines, sauf il y a un record separat sur le sous-domaine pour remplacer le record main. CAA records peuvent être utilisés à domaine unique ou domaines wildcard.

    Un CA doit vérifier l'existence d'un CAA record

    L'installation d'un CAA record par l'utilisateur n'est pas obligatoire. Cependant, il est recommandé comme une mesure supplémentaire de sécurité. À partir du 8 septembre 2017 est un CA obligatoire de vérifier ce record. Lors qu'au moins d'un record est disponible et le CA pour lequel vous voulez un certificat n'est pas disponible, le CA ne peut pas émettre un certificat pour le domaine. La vérification d'existence d'un CAA record a lieu pendant la création d'un certificat SSL. Si vous adaptez ou ajoutez un CAA record plus tard (par exemple un an plus tard), le certificat SSL qui est demandé avant cette date est valable.

    Vérifier CAA record?

    Vous pouvez vérifier l'existence d'un CAA record et la valeur, utiliser le Networking4all Qualys SSLLABS scan.

    Installer un CAA record

    L'installation d'un CAA record fonctionne selon un format défini. Celle-ci utilise trois différentes tags:

    • Issue: donne autorisation explicite au CA pour émettre un certificat pour le nom d'hôte.
    • Issuewild: donne autorisation explicite au CA pour émettre un wildcard certificat pour le nom d'hôte.
    • Iodef: donne un URL sur lequel un CA peut signaler des violations au protocole.

    Un de ces tags doivent être choisis pendant la création d'un CAA record. Un exemple d'un CAA record est:

    • CAA 0 issue "symantec.com"
    • CAA 0 iodef "mailto:abuse@networking4all.com"

    Une politique supplémentaire

    Il est possible de régler une politique supplémentaire pour un nom de domaine. En cela vous pouvez indiquer que pour ce nom de domaine ou nom d'hôte seulement certificats SSL EV peut être émis. Ci-dessous un exemple dans lequel seulement certificats EV peut être émis par le CA DigiCert:

    • CAA 0 issue "digicert.com; policy=ev"

    CAA records par CA

    Ci-dessous les exemples de CAA record par CA:

    • TrustProviderBV
      • CAA 0 issue "trustproviderbv.digitalcertvalidation.com"
      • CAA 0 issuewild "trustproviderbv.digitalcertvalidation.com"
    • DigiCert
      • CAA 0 issue "digicert.com"
      • CAA 0 issuewild "digicert.com"
    • Symantec
      • CAA 0 issue "symantec.com"
      • CAA 0 issuewild "symantec.com"
    • GeoTrust
      • CAA 0 issue "geotrust.com"
      • CCAA 0 issuewild "geotrust.com"
    • Thawte
      • CAA 0 issue "thawte.com"
      • CAA 0 issuewild "thawte.com"
    • RapidSSL
      • CAA 0 issue "rapidssl.com"
      • CAA 0 issuewild "rapidssl.com"
    • GlobalSign
      • CAA 0 issue "globalsign.com"
      • CAA 0 issuewild "globalsign.com"
    • AlphaSSL
      • CAA 0 issue "globalsign.com"
      • CAA 0 issuewild "globalsign.com"
  • Qu'est-ce qu'est OCSP?

    OCSP est Online Certificate Status Protocol. C'est un protocole de navigateur que vérifie la validité d'un certificat SSL à l'aide d'une liste blanche.

    CRL

    La validité est vérifiée normale à l'aide de liste de révocations de certificats (CRL): une liste noire d'autorité de certification sur laquelle le CA certificats placent qui sont révoqués. Chaque visite d'un site web avec un certificat, le navigateur fait une demande au CA, sur laquelle le CA renvoie le CRL. Ensuite le navigateur peut vérifier si le certificat en question est sur une liste noire. En ce cas, le navigateur peut donner un message d'erreur à l'utilisateur.

    L'utilisation d'un CRL a des désavantages: le navigateur doivent demander le CRL à nouveau ce que produit beaucoup de trafic au CA, particulièrement lorsqu'il s'agit un site web populaire avec beaucoup de trafic. Ce peut générer autant trafic que peut être abusé pour une attaque de DDoS. Si le CA n'est pas disponible, le CRL ne peut pas vérifier et le navigateur peut juger de confiance le certificat. En plus il est important de CA le CRL mises à jour.

    OCSP

    OCSP est créé pour offrir une alternative, et il travail avec une liste blanche au lieu d'une liste noire. Au lieu de demander une liste noire complète, le navigateur envoie le certificat qui doit être vérifié. Le CA envoie le statut du certificat au navigateur qui peut s'agir en conséquence. Cette méthode demande au moins de trafic au CA, et un règlement plus compact dans le navigateur, parce que seulement une petite réponse statut est traité. De plus le navigateur n'envoie pas l'utilisateur au site web quand il n'a pas de communication avec le CA: l'utilisateur recevrez un message d'erreur.

    Mais le OCSP a des désavantages: la chance d'une surcharge du système de CA est encore présent, mais plus moindre. La demande au CA est toujours sur HTTP, afin qu'il permet d'écouter pour hackers. Enfin il est discutable d'inclure un tiers pour la vérification d'un certificat, même si le tiers est le CA qui a émis le certificat.

    OCSP Stapling

    OCSP Stapling n'est pas le navigateur, mais le serveur qui contient le certificat qu'envoie une demande OCSP au CA. Ce processus est répété régulièrement: afin que le résultat reste mise à jour. Ensuite le serveur lie le résultat à la poignée de main SSL qui est appelée si un navigateur fait une connexion avec le serveur. Celui offre plusieurs avantages: il y a besoin plus de trafic entre le serveur et le navigateur, parce que la demande de navigateur est répondu directement avec la réponse de poignée de main SSL. La demande OCSP au CA à partir de serveur est un circuit fermé, et le résultat que le serveur reçoit doit être toujours signé par le CA pour être validé. Ce processus assure que le système ne peut pas exploiter. Le résultat est maintenu pendant longtemps, ce que fait plus stable que CRL ou OCSP. Si le CA n'est pas disponible, le serveur a un résultat que peut être utilisé pour vérification du certificat. Et quand le serveur ce résultat ne peut pas vérifier au navigateur, une demande OCSP peut être exécuté.

    OCSP Stapling est un paramètre sur votre installation serveur web. La configuration de cette option dépend du logiciel de votre serveur. Consulter le manuel d'utilisateur de votre logiciel pour configurer l'OCSP Stapling.

  • Qu'est-ce qu'est HTTP Strict Transport Security (HSTS)?

    HTTP Strict Transport Security, ou HSTS, est l'en-tête de réponse qui permet navigateurs de forcer les demandes suivantes qui sont envoient au serveur, en utilisant HTTPS. Celui signifie qu'une visite au http://www.networking4all.com est transmis automatiquement au https://www.networking4all.com, sans une demande pour le page HTTP. Celui prévient une attaque dégradée pendant une attaque Man in the Middle qui est appliquée sous une connexion non sécurisée au lieu d'une connexion HTTPS.

    HSTS fonctionne de telle manière que le trafic du site web n'est pas émis seulement à une connexion HTTPS, mais les liens sur la page externe sont aussi transmis à la page HTTPS. De plus, l'usage forcé de HTTPS prévient aussi d'être détourné la clé de session par les cookies.

    La configuration de HSTS est une question d'ajouter l'en-tête de réponse à la configuration:

    • Strict-Transport-Security: max-age= 31536000;

    Le serveur détermine que le HSTS pour un an ou 31.536.000 secondes, l'utilisation de HTTPS est obligatoire.

  • Comment fonctionne la validation de fichier?

    La validation de fichier est un type de vérification en utilisant d'émettre un certificat SSL. Cela signifie qu'un petit fichier est placé sur le serveur, que peut être lu par l'autorisation de certification.

    La validation de fichier seulement peut être utilisée via l'API et pour le certificats DV de Symantec, Thawte, GeoTrust et RapidSSL. Cette type de vérification est au lieu de vérification email.

    Le contenu de validation de fichier est envoyé dans une réponse d'API. Copiez ce texte et sauvegardez dans un fichier avec le nom 'verify.txt.'.

    L'approuver de fichier sera téléchargé sous la location sur le serveur:

    • GlobalSign commandes:votre nom commun/.well-known/pki-validation/verify.txt
    • Symantec commandes: votre nom commun/.well-known/pki-validation/fileauth.txt

    Plus d'information sur l'utilisation de validation de fichier, vous trouverez dans chapitre 5.3 de notre API documentation (en anglais).

Contact

Nous sommes disponibles téléphoniquement et sur notre chat aux heures de bureau.

Personnalisé

Personnalisé

Nous cherchons toujours une solution précise, si besoin est nous effectuons une intervention.
Disponible

Disponible

Nous sommes toujours disponibles par le biais d’un de nos canaux de communication.
Sécurité avant tout

Sécurité avant tout

Nous cherchons toujours des solutions pour une sécurité optimale.
Clarté et précision

Clarté et précision

Nous évoluons sans cesse afin de pouvoir vous servir au maximum pour votre sécurité numérique.
SSL, CODE SIGNING & DIGITAL IDS
SÉCURITÉ NUMÉRIQUE