PKI et SSL

Note : cette partie du support de formation est en cours de développement.

Objectifs de certification

LPIC 1

LPIC 2

1. Infrastructure à clé publique

1.1. Définition

Une infrastructure à clés publiques (ICP) ou infrastructure de gestion de clés (IGC) ou encore Public Key Infrastructure (PKI), est un ensemble de composants physiques (des ordinateurs, des équipements cryptographiques logiciels ou matériel type HSM ou encore des cartes à puces), de procédures humaines (vérifications, validation) et de logiciels (système et application) en vue de gérer le cycle de vie des certificats numériques ou certificats électroniques.

Une infrastructure à clés publiques fournit des garanties permettant de faire a priori confiance à un certificat signé par une autorité de certification grâce à un ensemble de services.

Ces services sont les suivants :

  • enregistrement des utilisateurs (ou équipement informatique) ;
  • génération de certificats ;
  • renouvellement de certificats ;
  • révocation de certificats ;
  • publication de certificats ;
  • publication des listes de révocation (comprenant la liste des certificats révoqués) ;
  • identification et authentification des utilisateurs (administrateurs ou utilisateurs qui accèdent à l'ICP) ;
  • archivage, séquestre et recouvrement des certificats (option).

1.2. Rôle d'une infrastructure à clés publiques

Une infrastructure à clés publiques (ICP) délivre des certificats numériques. Ces certificats permettent d'effectuer des opérations cryptographiques, comme le chiffrement et la signature numérique qui offrent les garanties suivantes lors des transactions électroniques :

  • confidentialité : elle garantit que seul le destinataire (ou le possesseur) légitime d'un bloc de données ou d'un message peut en avoir une vision intelligible ;
  • authentification : elle garantit à tout destinataire d'un bloc de données ou d'un message ou à tout système auquel tente de se connecter un utilisateur l'identité de l'expéditeur ou de l'utilisateur en question ;
  • intégrité : elle garantit qu'un bloc de données ou qu'un message n'a pas été altéré, accidentellement ou intentionnellement ;
  • non-répudiation : elle garantit à quiconque que l'auteur d'un bloc de données ou d'un message ne peut renier son œuvre, c'est-à-dire prétendre ne pas en être l'auteur.

Les ICP permettent l'obtention de ces garanties par l'application de processus de vérification d'identité rigoureux et par la mise en œuvre de solutions cryptographiques fiables (éventuellement évaluées), conditions indispensables à la production et à la gestion des certificats électroniques.

1.3. Composants de l'infrastructure à clés publiques

L'IETF distingue 4 catégories d'ICP :

  • l'autorité de certification (AC ou CA) qui signe les demandes de certificat (CSR : Certificate Signing Request) et les listes de révocation (CRL : Certificate Revocation List). Cette autorité est la plus critique ;
  • l'autorité d'enregistrement (AE ou RA) qui effectue les vérifications d'usage sur l'identité de l'utilisateur final (les certificats numériques sont nominatifs et uniques pour l'ensemble de l'ICP) ;
  • l'autorité de dépôt (Repository) qui stocke les certificats numériques ainsi que les listes de révocation (CRL) ;
  • l'entité finale (EE : End Entity) qui utilise le certificat (en général, le terme « entité d’extrémité » (EE) est préféré au terme « sujet » afin d’éviter la confusion avec le champ Subject).

En complément, on pourra ajouter une cinquième catégorie, non définie par l'IETF :

  • l'autorité de séquestre (Key Escrow) qui stocke de façon sécurisée les clés de chiffrement créées par les autorités d'enregistrement, pour pouvoir, le cas échéant, les restaurer. Les raisons à cela en sont multiples. La perte de la clef privée par son détenteur ne doit pas être définitive. Toute organisation doit être en mesure de déchiffrer les documents de travail d'un de ses membres si, par exemple, celui-ci n'en fait plus partie. Enfin, dans certains pays, en France en particulier, la loi exige que les données chiffrées puissent être déchiffrées à la demande des autorités nationales. La mise en œuvre d'un séquestre répond à cette exigence.

1.4. Les certificats numériques : Familles

Usuellement, on distingue deux familles de certificats numériques :

  • les certificats de signature, utilisés pour signer des documents ou s'authentifier sur un site web, et
  • les certificats de chiffrement (les gens qui vous envoient des courriels utilisent la partie publique de votre certificat pour chiffrer le contenu que vous serez seul à pouvoir déchiffrer)

Mais cette typologie n'est pas exhaustive ; un découpage plus orienté applicatif pourrait être envisagé. L'intérêt de la séparation des usages découle notamment des problématiques de séquestre de clés et de recouvrement. En effet, lorsqu'il y a chiffrement, il peut y avoir nécessité de recouvrer les informations chiffrées. Alors que lorsqu'il y a signature, il est indispensable de s'assurer que la clé privée n'est possédée que par une seule partie.

1.5. Nature et composition

Un certificat électronique est une donnée publique. Suivant la technique des clés asymétriques, à chaque certificat électronique correspond une clé privée, qui doit être soigneusement protégée.

Un certificat numérique porte les caractéristiques de son titulaire : si le porteur est un être humain, cela peut être son nom et son prénom, le nom de sa structure (par exemple, son entreprise ou son... État !) et de son entité d'appartenance. Si c'est un équipement informatique (comme une passerelle d'accès ou un serveur d'application sécurisé), le nom est remplacé par l'URI du service. À ces informations d'identification s'ajoute la partie publique du bi-clé.

L'ensemble de ces informations (comprenant la clé publique) est signé par l'autorité de certification de l'organisation émettrice. Cette autorité a la charge de :

  • s'assurer que les informations portées par le certificat numérique sont correctes ;
  • s'assurer qu'il n'existe, pour une personne et pour une même fonction, qu'un et un seul certificat valide à un moment donné.

Le certificat numérique est donc, à l'échelle d'une organisation, un outil pour témoigner, de façon électroniquement sûre, d'une identité.

L'usage conjoint des clés cryptographiques publiques (contenue dans le certificat) et privée (protégée par l'utilisateur, par exemple au sein d'une carte à puce), permet de disposer de fonctions de sécurité importante (cf. infra).

1.6. Gestion

Un certificat numérique naît après qu'une demande de certificat a abouti.

Une demande de certificat est un fichier numérique (appelé soit par son format, PKCS#10, soit par son équivalent fonctionnel, CSR pour Certificate Signing Request) qui est soumis à une autorité d'enregistrement par un utilisateur final ou par un administrateur pour le compte d'un utilisateur final.

Cette demande de certificat est examinée par un Opérateur d'Autorité d'Enregistrement. Cette position est une responsabilité clé : c'est lui qui doit juger de la légitimité de la demande de l'utilisateur et accorder, ou non, la confiance de l'organisation. Pour se forger une opinion, l'Opérateur doit suivre une série de procédures, plus ou moins complètes, consignées dans deux documents de référence qui vont de pair avec la création d'une ICP qui sont la Politique de Certification (PC) et la Déclaration des Pratiques de Certification (DPC). Ces documents peuvent exiger, en fonction des enjeux de la certification, des vérifications plus ou moins poussées : rencontre en face-à-face, validation hiérarchique, etc. L'objectif de l'Opérateur d'AE est d'assurer que les informations fournies par l'utilisateur sont exactes et que ce dernier est bien autorisé à solliciter la création d'un certificat.

Une fois son opinion formée, l'Opérateur de l'AE valide la demande ou la rejette. S'il la valide, la demande de certificat est alors adressée à l'Autorité de Certification (AC). L'AC vérifie que la demande a bien été validée par un Opérateur d'AE digne de confiance et, si c'est le cas, signe la CSR. Une fois signée, une CSR devient... un certificat.

Le certificat, qui ne contient aucune information confidentielle, peut par exemple être publié dans un annuaire d'entreprise : c'est la tâche du Module de Publication, souvent proche de l'AC.

1.7. Modes de création

Il existe deux façons distinctes de créer des certificats électroniques : le mode centralisé et le mode décentralisé.

le mode décentralisé est le mode le plus courant : il consiste à faire créer, par l'utilisateur (ou, plus exactement par son logiciel ou carte à puce) le biclé cryptographique et de joindre la partie publique de la clef dans la CSR. L'Infrastructure n'a donc jamais connaissance de la clé privée de l'utilisateur, qui reste confinée sur son poste de travail ou dans sa carte à puce.

le mode centralisé consiste en la création du biclé par l'AC : au début du cycle de la demande, la CSR ne contient pas la clé publique, c'est l'AC qui la produit. Elle peut ainsi avoir de bonnes garanties sur la qualité de la clé (aléa) et peut... en détenir une copie protégée. En revanche, il faut transmettre à l'utilisateur certes son certificat (qui ne contient que des données publiques) mais aussi sa clé privée ! L'ensemble de ces deux données est un fichier créé sous le format PKCS#12. Son acheminement vers l'utilisateur doit être entrepris avec beaucoup de précaution et de sécurité, car toute personne mettant la main sur un fichier PKCS#12 peut détenir la clé de l'utilisateur.

Le mode décentralisé est préconisé pour les certificats d'authentification (pour des questions de coût, parce qu'il est plus simple de refaire un certificat en décentralisé qu'à recouvrer une clé) et de signature (parce que les conditions d'exercice d'une signature juridiquement valide prévoit que le signataire doit être le seul possesseur de la clé : en mode décentralisé, l'ICP n'a jamais accès à la clé privée).

Le mode centralisé est préconisé pour les certificats de chiffrement, car, lorsqu'un utilisateur a perdu sa clé (par exemple, sa carte est perdue ou dysfonctionne), un opérateur peut, au terme d'une procédure de recouvrement, récupérer la clé de chiffrement et la lui remettre. Chose qui est impossible à faire avec des clés qui n'ont pas été séquestrées.

1.8. Scénario de fin de vie

Il existe deux scénarios possibles de fin de vie d'un certificat numérique :

  • le certificat numérique expire (chaque certificat numérique contient une date de « naissance » et une date de « péremption »).
  • le certificat est révoqué, pour quelque raison que ce soit (perte de la clé privée associée, etc.) et dans ce cas, l'identifiant du certificat numérique est ajouté à une liste de certificats révoqués (CRL pour Certificate Revocation List) pour informer les applications qu'elles ne doivent plus faire confiance à ce certificat. Il est aussi possible que les applications s'informent en quasi temps réel de l'état du certificat avec le protocole OCSP.

1.9. Autorité de certification

En cryptographie, une Autorité de Certification (AC ou CA pour Certificate Authority en anglais) est un tiers de confiance permettant d'authentifier l'identité des correspondants. Une autorité de certification délivre des certificats décrivant des identités numériques et met à disposition les moyens de vérifier la validité des certificats qu'elle a fourni.

Les services des autorités de certification sont principalement utilisés dans le cadre de la sécurisation des communications numériques via protocole Transport Layer Security (TLS) utilisé par exemple pour sécuriser les communications web (HTTPS) ou email (SMTP, POP3, IMAP... sur TLS), ainsi que pour la sécurisation des documents numériques (par exemple au moyen de signatures électroniques avancées telles que PAdES pour des documents PDF, ou via le protocole S/MIME pour les emails).

1.10. Utilisation dans le domaine des communications web

Les navigateurs web modernes intègrent nativement une liste de certificats provenant de différentes Autorités de Certification choisies selon des règles internes définies par les développeurs du navigateur.

Lorsqu'une personne physique ou morale souhaite mettre en place un serveur web utilisant une communication HTTPS sécurisée par TLS, elle génère une clé publique, une clé privée puis envoie à l'une de ces Autorité de Certification une demande de signature de certificat (en anglais CSR : Certificate Signing Request) contenant sa clé publique ainsi que des informations sur son identité (coordonnées postales, téléphoniques, email...).

Après vérification de l'identité du demandeur du certificat par une autorité d'enregistrement (RA), l'Autorité de Certification signe le CSR grâce à sa propre clé privée (et non pas avec la clé privée de la personne donc) qui devient alors un certificat puis le transmet en retour à la personne qui en a fait la demande.

Le certificat ainsi retourné sous forme de fichier informatique est intégré dans le serveur web du demandeur. Lorsqu'un utilisateur se connecte à ce serveur web, celui-ci lui transmet à son tour le certificat fourni précédemment par l'Autorité de Certification.

Le navigateur web du client authentifie le certificat du serveur grâce au certificat de l'Autorité de Certification (intégré nativement dans le navigateur, cf. ci-dessus) qui l'a signé précédemment. L'identité du serveur est ainsi confirmée à l'utilisateur par l'Autorité de Certification.

Le navigateur web contacte ensuite l'Autorité de Certification concernée pour savoir si le certificat du serveur n'a pas été révoqué (= invalidé) depuis qu'il a été émis par l'Autorité de Certification via une demande OCSP.

Auparavant, les navigateurs téléchargeaient régulièrement des listes de révocation (CRL : Certificate Revocation List) de la part des Autorités de Certification au lieu de contacter directement celles-ci par des demandes OCSP. Ce processus a été abandonné depuis car utilisant inutilement beaucoup de bande passante.

Sur le plan technique, cette infrastructure de gestion des clés permet ainsi d'assurer que :

  • les données transmises entre le serveur web et le client n'ont pas été modifiées durant le transfert : intégrité par hachage des données.
  • les données proviennent bien du serveur web connu et qu'il ne s'agit pas d'un serveur web tiers tentant d'usurper l'identité de celui-ci.
  • les données ne peuvent pas être interceptées par un tiers car elles sont chiffrées.

1.11. Fonctionnement interne

L'autorité de certification (AC) opère elle-même ou peut déléguer l'hébergement de la clé privée du certificat à un opérateur de certification (OC) ou autorité de dépôt. L'AC contrôle et audite l'opérateur de certification sur la base des procédures établies dans la Déclaration des Pratiques de Certification. L'AC est accréditée par une autorité de gestion de la politique qui lui permet d'utiliser un certificat renforcé utilisé par l'OC pour signer la clé publique selon le principe de la signature numérique.

2. Certificats électroniques

Un certificat électronique (aussi appelé certificat numérique ou certificat de clé publique) peut être vu comme une carte d'identité numérique. Il est utilisé principalement pour identifier et authentifier une personne physique ou morale, mais aussi pour chiffrer des échanges.

Il est signé par un tiers de confiance qui atteste du lien entre l'identité physique et l'entité numérique (virtuelle).

Le standard le plus utilisé pour la création des certificats numériques est le X.509.

2.1. Définition

Un certificat électronique est un ensemble de données contenant :

  • au moins une clé publique ;
  • des informations d'identification, par exemple : nom, localisation, adresse électronique ;
  • au moins une signature (clé privée) ; de fait quand il n'y en a qu'une, l'entité signataire est la seule autorité permettant de prêter confiance (ou non) à l'exactitude des informations du certificat.

Les certificats électroniques et leur cycle de vie (voir liste de révocation de certificats et protocole de vérification de certificat en ligne) peuvent être gérés au sein d'infrastructures à clés publiques.

2.2. Types

Les certificats électroniques respectent des standards spécifiant leur contenu de façon rigoureuse. Les deux formats les plus utilisés aujourd'hui sont :

  • X.509, défini dans la RFC 5280 ;
  • OpenPGP, défini dans la RFC 4880.

La différence notable entre ces deux formats est qu'un certificat X.509 ne peut contenir qu'un seul identifiant, que cet identifiant doit contenir de nombreux champs prédéfinis, et ne peut être signé que par une seule autorité de certification. Un certificat OpenPGP peut contenir plusieurs identifiants, lesquels autorisent une certaine souplesse sur leur contenu, et peuvent être signés par une multitude d'autres certificats OpenPGP, ce qui permet alors de construire des toiles de confiance.

2.3. Utilité

Les certificats électroniques sont utilisés dans différentes applications informatiques dans le cadre de la sécurité des systèmes d'information pour garantir :

  • la non-répudiation et l'intégrité des données avec la signature numérique ;
  • la confidentialité des données grâce au chiffrement des données ;
  • l'authentification ou l'authentification forte d'un individu ou d'une identité numérique.

2.4. Exemples d'utilisation

  • Serveur web (voir TLS et X.509) ;
  • Courrier électronique (voir OpenPGP) ;
  • Poste de travail (voir IEEE 802.1X) ;
  • Réseau privé virtuel (VPN, voir IPsec) ;
  • Secure Shell (SSH), TLS ;
  • Documents électroniques.

3. Transport Layer Security

Transport Layer Security (TLS), et son prédécesseur Secure Sockets Layer (SSL), sont des protocoles de sécurisation des échanges sur Internet. Le protocole SSL a été développé à l'origine par Netscape. L'IETF, en a poursuivi le développement en le rebaptisant Transport Layer Security (TLS). On parle parfois de SSL/TLS pour désigner indifféremment SSL ou TLS.

TLS (ou SSL) fonctionne suivant un mode client-serveur. Il permet de satisfaire aux objectifs de sécurité suivants :

  • l'authentification du serveur ;
  • la confidentialité des données échangées (ou session chiffrée) ;
  • l'intégrité des données échangées ;
  • de manière optionnelle, l'authentification du client (mais dans la réalité celle-ci est souvent assurée par le serveur).

Le protocole est très largement utilisé, sa mise en œuvre est facilitée par le fait que les protocoles de la couche application, comme HTTP, n'ont pas à être profondément modifiés pour utiliser une connexion sécurisée, mais seulement implémentés au-dessus de SSL/TLS, ce qui pour HTTP a donné le protocole HTTPS.

Un groupe de travail spécial de l'IETF a permis la création du TLS et de son équivalent en mode UDP, le DTLS. Depuis qu'il est repris par l'IETF, le protocole TLS a connu trois versions, TLS v1.0 en 1999, TLS v1.1 en 2006 et TLS v1.2 en 2008. Un premier brouillon de TLS v1.3 est sorti en 2014.

3.1. Présentation

Au fur et à mesure qu'Internet se développait, de plus en plus de sociétés commerciales se mirent à proposer des achats en ligne pour les particuliers. L'offre se mit à croître régulièrement, mais le chiffre d'affaires dégagé par le commerce électronique restait modeste tant que les clients n'avaient pas une confiance suffisante dans le paiement par carte bancaire. Une des façons de sécuriser ce paiement fut d'utiliser des protocoles d'authentification et de chiffrement tels que SSL. La session chiffrée est utilisée pour empêcher un tiers d'intercepter des données sensibles transitant par le réseau : numéro de carte lors d'un paiement par carte bancaire, mot de passe lorsque l'utilisateur s'identifie sur un site…

Avec un système SSL, la sécurité a été sensiblement améliorée et les risques pour le client grandement réduits, comparés à l'époque où le paiement par internet était encore une technologie émergente. Bien que, comme tout système de chiffrement, le SSL/TLS ne pourra jamais être totalement infaillible, le grand nombre de banques et de sites de commerce électronique l'utilisant pour protéger les transactions de leurs clients peut être considéré comme un gage de sa résistance aux attaques malveillantes.

En 2009, TLS est utilisé par la plupart des navigateurs Web. L'internaute peut reconnaître qu'une transaction est chiffrée à plusieurs signes :

  • l'URL dans la barre d'adresse commence par https et non http (https://...) ;
  • affichage d'une clé ou d'un cadenas, dont l'emplacement varie selon le navigateur : généralement à gauche de la barre d'adresse mais aussi dans la barre inférieure de la fenêtre ;
  • les navigateurs peuvent ajouter d'autres signes, comme le passage en jaune de la barre d'adresse (cas de Firefox).

Il existe quelques cas très spécifiques où la connexion peut être sécurisée par SSL sans que le navigateur n'affiche ce cadenas, notamment si le webmaster a inclus la partie sécurisée du code HTML au sein d'une page en http ordinaire, mais cela reste rare. Dans la très grande majorité des cas, l'absence de cadenas indique que les données ne sont pas protégées et seront transmises en clair.

3.2. Protocole SSL

La première version de SSL parue, la SSL 2.0, possédait un certain nombre de défauts de sécurité, parmi lesquels la possibilité de forcer l'utilisation d'algorithmes de chiffrement plus faibles, ou bien une absence de protection pour la prise de contact et la possibilité pour un attaquant d'exécuter des attaques par troncature1. Les protocoles PCT 1.0, puis SSL 3.0, furent développés pour résoudre la majeure partie de ces problèmes, le second devenant rapidement le protocole le plus populaire pour sécuriser les échanges sur Internet.

  • 1994 : SSL 1.0. Cette première spécification du protocole développé par Netscape resta théorique et ne fut jamais mise en œuvre3.
  • Février 1995 : publication de la norme SSL 2.0, première version de SSL réellement utilisée. Elle fut également la première implémentation de SSL bannie, en mars 2011 (RFC 6176).
  • Novembre 1996 : SSL 3.0, la dernière version de SSL, qui inspirera son successeur TLS. Ses spécifications sont rééditées en août 2008 dans la RFC 61014. Le protocole est banni en 2014, à la suite de la publication de la faille POODLE, ce bannissement est définitivement ratifié en juin 2015 (RFC 7568).

3.3. Protocole TLS

Le protocole TLS n'est pas structurellement différent de la version 3 de SSL, mais des modifications dans l'utilisation des fonctions de hachage font que les deux protocoles ne sont pas directement interopérables. Cependant TLS, comme SSLv3, intègre un mécanisme de compatibilité ascendante avec les versions précédentes, c'est-à-dire qu'au début de la phase de négociation, le client et le serveur négocient la « meilleure » version du protocole disponible par tous deux. Pour des raisons de sécurité, détaillées dans la RFC 6176 parue en 2011, la compatibilité de TLS avec la version 2 de SSL est abandonnée5.

La génération des clés symétriques est un peu plus sécurisée dans TLS que dans SSLv3 dans la mesure où aucune étape de l'algorithme ne repose uniquement sur MD5 pour lequel sont apparues des faiblesses en cryptanalyse.

  • Janvier 1999 (RFC 2246) : Publication de la norme TLS 1.0. TLS est le protocole développé par l'IETF pour succéder au SSL. Plusieurs améliorations lui sont apportées par la suite :
  • Octobre 1999 (RFC 2712) : Ajout du protocole Kerberos à TLS ;
  • Mai 2000 (RFC 2817 et RFC 2818) : Passage à TLS lors d'une session HTTP 1.1 ;
  • Juin 2002 (RFC 3268) : Support du système de chiffrement AES par TLS.
  • Avril 2006 (RFC 4346) : Publication de la norme TLS 1.1.
  • Août 2008 (RFC 5246) : Publication de la norme TLS 1.2.
  • Mars 2011 (RFC 6176) : Abandon de la compatibilité avec SSLv2 pour toutes les versions de TLS.
  • Avril 2014 : 1er brouillon pour TLS 1.36.
  • Juin 2015 (RFC 7568) : Abandon de la compatibilité avec SSLv2 et SSLv3.
  • Octobre 2015 : Nouveau brouillon de TLS 1.37

3.4. Spécifications techniques

Dans la pile de protocole TCP/IP, SSL se situe entre la couche application (comme HTTP, FTP, SMTP, etc.) et la couche transport TCP.

Son utilisation la plus commune reste cependant en dessous de HTTP. Le protocole SSL est implémenté par la couche session de la pile, ce qui a deux conséquences :

  • pour toute application existante utilisant TCP, il peut exister une application utilisant SSL. Par exemple, l'application HTTPS correspond à HTTP au-dessus de SSL ;
  • une application SSL se voit attribuer un nouveau numéro de port par l'IANA. Par exemple HTTPS est associé au port 443. Dans certains cas, le même port est utilisé avec et sans SSL. Dans ce cas, la connexion est initiée en mode non chiffré. Le tunnel est ensuite mis en place au moyen du mécanisme StartTLS. C'est le cas, par exemple, des protocoles IMAP, SMTP ou LDAP.

La sécurité est réalisée d'une part par un chiffrement asymétrique, comme le chiffrement RSA, qui permet, après authentification de la clé publique du serveur, la constitution d'un secret partagé entre le client et le serveur, d'autre part par un chiffrement symétrique (beaucoup plus rapide que les chiffrements asymétriques), comme l'AES, qui est utilisé dans la phase d'échange de données, les clés de chiffrement symétrique étant calculées à partir du secret partagé. Une fonction de hachage, comme SHA-1, est également utilisée, entre autres, pour assurer l'intégrité et l'authentification des données (via par exemple HMAC).

3.5. Mise en oeuvre de TLS

...

4. Pratique de TLS et des certificats

4.1. Récupérer, visualiser, transcoder un certificat

  • Visualiser un certificat :
# cat /etc/pki/tls/certs/localhost.crt
  • Mieux présenté avec openssl :
# openssl x509 -text -noout -in /etc/pki/tls/certs/localhost.crt
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 28890 (0x70da)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=--, ST=SomeState, L=SomeCity, O=SomeOrganization, OU=SomeOrganizationalUnit, CN=localhost.localdomain/emailAddress=root@localhost.localdomain
        Validity
            Not Before: Sep 26 13:57:53 2016 GMT
            Not After : Sep 26 13:57:53 2017 GMT
        Subject: C=--, ST=SomeState, L=SomeCity, O=SomeOrganization, OU=SomeOrganizationalUnit, CN=localhost.localdomain/emailAddress=root@localhost.localdomain
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:9d:fd:05:7b:39:c2:75:62:ac:41:9b:96:5d:af:
                    94:2e:80:d2:50:99:1a:9e:ad:6c:2b:ce:1a:6f:e5:
                    4c:2e:51:f2:13:13:b5:05:2f:f6:ac:42:97:96:a2:
                    52:3e:55:8b:70:fa:bb:af:93:7a:f7:a3:8f:a4:2e:
                    6e:cc:eb:53:1d:81:ed:58:8d:69:c1:6e:0e:e9:22:
                    89:46:55:e8:8a:fc:46:1a:c3:28:f3:38:c5:e4:8a:
                    4b:83:9a:96:79:e7:e4:53:4f:75:d9:5b:47:4f:5e:
                    88:e9:7a:a6:30:ef:a4:e0:ed:8e:02:6d:70:79:ea:
                    17:84:dc:41:75:7e:95:94:9f:dd:2b:fc:1b:15:a0:
                    5d:71:b1:5f:29:51:4a:0c:d4:0b:2e:8b:f8:4c:d8:
                    40:d1:b4:f9:1c:e7:18:d4:43:49:6b:81:f0:87:73:
                    b6:1c:a5:95:52:65:f8:72:33:1f:ad:3f:07:8f:7c:
                    44:3c:3d:64:e4:3f:7c:ea:79:db:a4:d7:ef:64:1f:
                    84:d6:81:cc:cc:1c:87:da:61:33:96:41:4b:7a:02:
                    84:a3:f0:ee:82:e0:93:e3:d5:fd:26:45:bc:f0:a1:
                    24:fc:d3:74:1e:8e:96:60:f7:4d:77:92:ca:a1:5a:
                    dc:26:6c:52:d9:d7:ea:3b:30:bc:67:36:1f:24:83:
                    6a:df
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Key Usage:
                Digital Signature, Non Repudiation, Key Encipherment
    Signature Algorithm: sha256WithRSAEncryption
         0c:06:72:8d:6d:29:ae:a5:5b:bf:8d:57:6e:7b:ff:82:98:ad:
         30:39:5f:6c:dc:cb:58:84:cc:ca:bc:cb:01:db:6f:e0:05:98:
         50:e0:88:8a:69:e7:7e:75:26:89:60:a8:ec:c7:b6:62:ef:b0:
         7e:9a:93:72:f6:89:d9:ef:f5:e8:33:a0:d2:92:b0:9a:95:5c:
         ee:21:83:d6:5f:88:df:89:b4:9d:3b:27:02:5d:b4:34:b8:00:
         e0:75:32:1e:77:71:3d:0b:62:82:43:a5:8a:71:30:9c:f2:56:
         e1:69:6f:25:a6:84:7b:b8:57:0a:f7:14:a1:f4:aa:0d:39:0e:
         4b:7d:5b:c9:06:d5:70:04:a4:bd:9e:e2:ca:46:80:90:36:e2:
         f0:12:f1:b5:0f:b5:da:21:d8:31:f3:c1:27:d3:47:b2:df:7b:
         9e:7c:86:2a:d2:25:57:83:70:5b:c0:c4:63:48:d8:56:f9:53:
         90:d9:7d:b0:a7:9e:38:0e:41:c9:c4:16:a5:55:5a:c3:1c:3c:
         7b:4d:51:2d:bb:a5:e0:af:96:6d:95:3d:d4:21:0f:5a:48:2c:
         83:92:a5:64:1e:57:65:8a:45:cf:5d:f2:d2:d0:d1:2d:6a:7c:
         18:df:ff:b2:bf:8f:f4:fe:78:10:b1:f4:82:31:19:96:b8:bd:
         11:b1:99:b2
  • Récupérer un certicat X509 en ligne
# openssl s_client -showcerts -connect www.linux.com:443
CONNECTED(00000003)
depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
verify return:1
depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign CloudSSL CA - SHA256 - G3
verify return:1
depth=0 C = US, ST = California, L = San Francisco, O = "Fastly, Inc.", CN = n.ssl.fastly.net
verify return:1
---
Certificate chain
 0 s:/C=US/ST=California/L=San Francisco/O=Fastly, Inc./CN=n.ssl.fastly.net
   i:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign CloudSSL CA - SHA256 - G3
-----BEGIN CERTIFICATE-----
MIIOdjCCDV6gAwIBAgIMDvskHGiB0MJcky5oMA0GCSqGSIb3DQEBCwUAMFcxCzAJ
...
hLx9Lj/Y6X4/9l5lxjSFf5y+M9WHVWAR3VQ1dpTkkXfarj1eIRxZS2LsvBJjgw8b
XgwBVqdmBNkD0g==
-----END CERTIFICATE-----
 1 s:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign CloudSSL CA - SHA256 - G3
   i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
-----BEGIN CERTIFICATE-----
MIIEizCCA3OgAwIBAgIORvCM288sVGbvMwHdXzQwDQYJKoZIhvcNAQELBQAwVzEL
...
HY7EDGiWtkdREPd76xUJZPX58GMWLT3fI0I6k2PMq69PVwbH/hRVYs4nERnh9ELt
IjBrNRpKBYCkZd/My2/Q
-----END CERTIFICATE-----
---
Server certificate
subject=/C=US/ST=California/L=San Francisco/O=Fastly, Inc./CN=n.ssl.fastly.net
issuer=/C=BE/O=GlobalSign nv-sa/CN=GlobalSign CloudSSL CA - SHA256 - G3
---
No client certificate CA names sent
Server Temp Key: ECDH, prime256v1, 256 bits
---
SSL handshake has read 5535 bytes and written 373 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: 639EF6139293984B77BA686502009FA32EE55CA40892D3772ECE1559DE411BA6
    Session-ID-ctx:
    Master-Key: 69CDFB6E8807850C181CE54D66676762FE1B6E5F8FE79B2D8E9CB6782EF6E5BA4A58835BC5BE3FFCC7EC11EABEB48EFD
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    TLS session ticket lifetime hint: 1200 (seconds)
    TLS session ticket:
    0000 - 63 cc 77 4a 00 db 2c 42-2e 8f 76 23 dd a9 ae 53   c.wJ..,B..v#...S
    0010 - eb f3 5b 75 31 9c 7e dd-34 0e 27 9e c5 87 6f 3e   ..[u1.~.4.'...o>
    0020 - fb fd 08 7f 4c 97 d1 e6-88 67 32 e6 95 9e 70 ee   ....L....g2...p.
    0030 - 1c 8f f2 1a 98 b6 5e 20-3d b9 14 c3 c0 61 36 5b   ......^ =....a6[
    0040 - a6 05 43 fa bc 4c b3 58-8f a4 10 76 18 a0 11 12   ..C..L.X...v....
    0050 - 1b be 0d 04 48 85 a1 44-ea fb ad a0 3d 13 85 51   ....H..D....=..Q
    0060 - 1a fb f6 95 a1 1e 06 c2-e2 c7 ba 8b de 52 9e 1d   .............R..
    0070 - 64 56 db 5a c8 0b 82 43-84 6d a0 2f 0a ef 8e ef   dV.Z...C.m./....
    0080 - 73 64 b9 c7 c3 37 d0 ce-62 d5 44 0d fd cc 2f b4   sd...7..b.D.../.
    0090 - ea 34 8c a5 eb 0f 4b 0b-2b c9 bb 58 ec c8 44 e2   .4....K.+..X..D.

    Start Time: 1475086354
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
  • Transcodage PEM/DER

4.2. Créer un certificat x509 auto-signé

  • Création de la clé privée server.key
# openssl genrsa -out server.key 2048
Generating RSA private key, 2048 bit long modulus
.........................................+++
..................................................................................................................................................................................+++
e is 65537 (0x10001)

# chmod 440 server.key
  • Avec la clé privée, création d'un fichier de demande de signature de certificat (CSR Certificate Signing Request) :
# openssl req -new -key server.key -out server.req
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:BE
State or Province Name (full name) []:Brussels
Locality Name (eg, city) [Default City]:Brussels
Organization Name (eg, company) [Default Company Ltd]:Linux
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
  • Auto-signature :
# openssl x509 -req -days 365 -in server.req -signkey server.key -out server.crt
Signature ok
subject=/C=BE/ST=Brussels/L=Brussels/O=Linux
Getting Private key
  • Affichage du certificat :
# openssl x509 -text -noout -in server.crt
Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number: 10940766965370417421 (0x97d569969d3b710d)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=BE, ST=Brussels, L=Brussels, O=Linux
        Validity
            Not Before: Sep 28 18:31:12 2016 GMT
            Not After : Sep 28 18:31:12 2017 GMT
        Subject: C=BE, ST=Brussels, L=Brussels, O=Linux
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:c4:1e:20:7c:04:56:ec:24:ef:df:02:d6:6e:95:
                    79:98:24:b1:76:51:3e:2d:46:e0:4a:b1:35:16:92:
                    7e:06:8d:03:2f:fd:6d:6f:e5:48:64:1c:11:d4:48:
                    40:08:27:53:a0:9c:cc:87:f9:f5:80:8a:44:9a:a6:
                    32:ba:30:a0:94:d9:0c:76:d0:db:26:a8:52:62:83:
                    2a:43:c1:c8:bf:36:49:a9:35:21:50:79:48:35:ca:
                    10:cf:15:f3:60:87:d2:f1:3e:b0:af:12:81:02:2e:
                    20:3a:29:a4:f2:8c:15:07:27:07:4c:05:27:b9:b6:
                    b3:d8:01:ff:77:13:ce:48:c7:ad:4c:08:64:af:39:
                    7d:1a:15:cf:aa:bd:7b:c3:d6:ae:21:7b:1f:d6:fa:
                    cc:af:39:ac:34:9e:fa:f7:a2:38:1e:b5:7b:d7:67:
                    c5:b2:9b:b5:08:af:55:27:08:87:16:8f:a4:5a:e4:
                    6f:ee:9f:05:0b:59:a1:d6:90:8e:96:66:d1:98:89:
                    27:43:ae:ba:60:f9:0d:9a:e9:1d:f4:07:a6:25:f3:
                    41:d5:a7:bc:78:4b:94:23:98:81:cf:32:1b:92:0a:
                    46:35:b7:1b:80:03:ca:14:f3:57:89:db:9c:3d:1e:
                    b3:79:61:8d:2c:49:0c:12:6b:22:fc:d1:44:64:cd:
                    e6:f1
                Exponent: 65537 (0x10001)
    Signature Algorithm: sha1WithRSAEncryption
         79:d6:0b:23:54:0b:16:cd:00:09:8a:1e:fb:cb:33:a4:8a:73:
         c8:38:54:6f:72:e6:37:81:bf:ed:18:67:18:96:93:a0:9d:d1:
         92:45:de:3f:f1:c8:16:75:fb:e1:b6:b6:e3:b8:91:a3:f8:65:
         d4:54:09:dd:e8:2a:ba:5e:23:e0:6a:e4:a1:31:61:85:f7:7a:
         7a:7a:24:4e:c9:ed:c4:ed:e1:f9:2f:d0:bd:a2:9b:ec:32:3b:
         c8:b0:2c:56:40:c7:69:ea:cd:52:1e:60:2f:31:92:3e:90:e0:
         c3:77:59:8b:a9:1e:dc:33:44:da:99:dc:3a:21:ad:df:c4:9a:
         c8:53:42:0b:9e:67:83:7f:3e:3f:82:18:07:12:5f:4b:12:ca:
         65:8c:a9:ee:00:ab:b5:39:bd:e0:33:0f:c9:d6:db:cc:d2:f3:
         1b:bb:6e:fe:bc:c4:2c:a6:e6:de:ee:e0:ba:ff:68:1b:9b:17:
         e5:3c:83:7d:c1:03:95:8a:84:44:53:1d:fc:97:a5:2c:17:74:
         41:80:39:f7:a9:18:7c:9d:6b:5c:cb:87:83:d3:aa:4b:f6:c7:
         f0:e6:5c:4a:ce:f2:a3:b5:ef:a6:4b:c4:e0:54:66:cf:e3:3e:
         42:df:e4:a8:9d:9e:97:14:6a:eb:e2:2d:5b:23:a7:68:56:82:
         ad:b3:6e:19

4.3. Tester une liaison SSL

  • Arrêter le pare-feu
# systemctl stop firewalld
# iptables -X
# iptables -F
# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

...

4.4. Créer un CA, signer des certificats (1)

4.5. Créer un CA, signer des certificats (2)

4.6. Révoquer un certificat

4.7. Créer un certificat pour une personne

4.8. Configurer Apache/Nginx en HTTPS

SSL avec Lets Encrypt

4.9. Créer un tunnel OpenVPN

https://github.com/Nyr/openvpn-install/blob/master/openvpn-install.sh

#!/bin/bash
# OpenVPN road warrior installer for Debian, Ubuntu and CentOS

# This script will work on Debian, Ubuntu, CentOS and probably other distros
# of the same families, although no support is offered for them. It isn't
# bulletproof but it will probably work if you simply want to setup a VPN on
# your Debian/Ubuntu/CentOS box. It has been designed to be as unobtrusive and
# universal as possible.


if [[ "$EUID" -ne 0 ]]; then
    echo "Sorry, you need to run this as root"
    exit 1
fi


if [[ ! -e /dev/net/tun ]]; then
    echo "TUN/TAP is not available"
    exit 2
fi


if grep -qs "CentOS release 5" "/etc/redhat-release"; then
    echo "CentOS 5 is too old and not supported"
    exit 3
fi

if [[ -e /etc/debian_version ]]; then
    OS=debian
    RCLOCAL='/etc/rc.local'
elif [[ -e /etc/centos-release || -e /etc/redhat-release ]]; then
    OS=centos
    RCLOCAL='/etc/rc.d/rc.local'
    # Needed for CentOS 7
    chmod +x /etc/rc.d/rc.local
else
    echo "Looks like you aren't running this installer on a Debian, Ubuntu or CentOS system"
    exit 4
fi

newclient () {
    # Generates the custom client.ovpn
    cp /etc/openvpn/client-common.txt ~/$1.ovpn
    echo "<ca>" >> ~/$1.ovpn
    cat /etc/openvpn/easy-rsa/pki/ca.crt >> ~/$1.ovpn
    echo "</ca>" >> ~/$1.ovpn
    echo "<cert>" >> ~/$1.ovpn
    cat /etc/openvpn/easy-rsa/pki/issued/$1.crt >> ~/$1.ovpn
    echo "</cert>" >> ~/$1.ovpn
    echo "<key>" >> ~/$1.ovpn
    cat /etc/openvpn/easy-rsa/pki/private/$1.key >> ~/$1.ovpn
    echo "</key>" >> ~/$1.ovpn
}


# Try to get our IP from the system and fallback to the Internet.
# I do this to make the script compatible with NATed servers (lowendspirit.com)
# and to avoid getting an IPv6.
IP=$(ip addr | grep 'inet' | grep -v inet6 | grep -vE '127\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' | grep -o -E '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' | head -1)
if [[ "$IP" = "" ]]; then
        IP=$(wget -qO- ipv4.icanhazip.com)
fi


if [[ -e /etc/openvpn/server.conf ]]; then
    while :
    do
    clear
        echo "Looks like OpenVPN is already installed"
        echo ""
        echo "What do you want to do?"
        echo "   1) Add a cert for a new user"
        echo "   2) Revoke existing user cert"
        echo "   3) Remove OpenVPN"
        echo "   4) Exit"
        read -p "Select an option [1-4]: " option
        case $option in
            1)
            echo ""
            echo "Tell me a name for the client cert"
            echo "Please, use one word only, no special characters"
            read -p "Client name: " -e -i client CLIENT
            cd /etc/openvpn/easy-rsa/
            ./easyrsa build-client-full $CLIENT nopass
            # Generates the custom client.ovpn
            newclient "$CLIENT"
            echo ""
            echo "Client $CLIENT added, certs available at ~/$CLIENT.ovpn"
            exit
            ;;
            2)
            # This option could be documented a bit better and maybe even be simplimplified
            # ...but what can I say, I want some sleep too
            NUMBEROFCLIENTS=$(tail -n +2 /etc/openvpn/easy-rsa/pki/index.txt | grep -c "^V")
            if [[ "$NUMBEROFCLIENTS" = '0' ]]; then
                echo ""
                echo "You have no existing clients!"
                exit 5
            fi
            echo ""
            echo "Select the existing client certificate you want to revoke"
            tail -n +2 /etc/openvpn/easy-rsa/pki/index.txt | grep "^V" | cut -d '=' -f 2 | nl -s ') '
            if [[ "$NUMBEROFCLIENTS" = '1' ]]; then
                read -p "Select one client [1]: " CLIENTNUMBER
            else
                read -p "Select one client [1-$NUMBEROFCLIENTS]: " CLIENTNUMBER
            fi
            CLIENT=$(tail -n +2 /etc/openvpn/easy-rsa/pki/index.txt | grep "^V" | cut -d '=' -f 2 | sed -n "$CLIENTNUMBER"p)
            cd /etc/openvpn/easy-rsa/
            ./easyrsa --batch revoke $CLIENT
            ./easyrsa gen-crl
            rm -rf pki/reqs/$CLIENT.req
            rm -rf pki/private/$CLIENT.key
            rm -rf pki/issued/$CLIENT.crt
            rm -rf /etc/openvpn/crl.pem
            cp /etc/openvpn/easy-rsa/pki/crl.pem /etc/openvpn/crl.pem
            # And restart
            if pgrep systemd-journal; then
                systemctl restart openvpn@server.service
            else
                if [[ "$OS" = 'debian' ]]; then
                    /etc/init.d/openvpn restart
                else
                    service openvpn restart
                fi
            fi
            echo ""
            echo "Certificate for client $CLIENT revoked"
            exit
            ;;
            3)
            echo ""
            read -p "Do you really want to remove OpenVPN? [y/n]: " -e -i n REMOVE
            if [[ "$REMOVE" = 'y' ]]; then
                PORT=$(grep '^port ' /etc/openvpn/server.conf | cut -d " " -f 2)
                if pgrep firewalld; then
                    # Using both permanent and not permanent rules to avoid a firewalld reload.
                    firewall-cmd --zone=public --remove-port=$PORT/udp
                    firewall-cmd --zone=trusted --remove-source=10.8.0.0/24
                    firewall-cmd --permanent --zone=public --remove-port=$PORT/udp
                    firewall-cmd --permanent --zone=trusted --remove-source=10.8.0.0/24
                fi
                if iptables -L | grep -qE 'REJECT|DROP'; then
                    sed -i "/iptables -I INPUT -p udp --dport $PORT -j ACCEPT/d" $RCLOCAL
                    sed -i "/iptables -I FORWARD -s 10.8.0.0\/24 -j ACCEPT/d" $RCLOCAL
                    sed -i "/iptables -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT/d" $RCLOCAL
                fi
                sed -i '/iptables -t nat -A POSTROUTING -s 10.8.0.0\/24 -j SNAT --to /d' $RCLOCAL
                if which sestatus; then
                    if sestatus | grep "Current mode" | grep -qs "enforcing"; then
                        if [[ "$PORT" != '1194' ]]; then
                            semanage port -d -t openvpn_port_t -p udp $PORT
                        fi
                    fi
                fi
                if [[ "$OS" = 'debian' ]]; then
                    apt-get remove --purge -y openvpn openvpn-blacklist
                else
                    yum remove openvpn -y
                fi
                rm -rf /etc/openvpn
                rm -rf /usr/share/doc/openvpn*
                echo ""
                echo "OpenVPN removed!"
            else
                echo ""
                echo "Removal aborted!"
            fi
            exit
            ;;
            4) exit;;
        esac
    done
else
    clear
    echo 'Welcome to this quick OpenVPN "road warrior" installer'
    echo ""
    # OpenVPN setup and first user creation
    echo "I need to ask you a few questions before starting the setup"
    echo "You can leave the default options and just press enter if you are ok with them"
    echo ""
    echo "First I need to know the IPv4 address of the network interface you want OpenVPN"
    echo "listening to."
    read -p "IP address: " -e -i $IP IP
    echo ""
    echo "What port do you want for OpenVPN?"
    read -p "Port: " -e -i 1194 PORT
    echo ""
    echo "What DNS do you want to use with the VPN?"
    echo "   1) Current system resolvers"
    echo "   2) Google"
    echo "   3) OpenDNS"
    echo "   4) NTT"
    echo "   5) Hurricane Electric"
    read -p "DNS [1-6]: " -e -i 1 DNS
    echo ""
    echo "Finally, tell me your name for the client cert"
    echo "Please, use one word only, no special characters"
    read -p "Client name: " -e -i client CLIENT
    echo ""
    echo "Okay, that was all I needed. We are ready to setup your OpenVPN server now"
    read -n1 -r -p "Press any key to continue..."
        if [[ "$OS" = 'debian' ]]; then
        apt-get update
        apt-get install openvpn iptables openssl ca-certificates -y
    else
        # Else, the distro is CentOS
        yum install epel-release -y
        yum install openvpn iptables openssl wget ca-certificates -y
    fi
    # An old version of easy-rsa was available by default in some openvpn packages
    if [[ -d /etc/openvpn/easy-rsa/ ]]; then
        rm -rf /etc/openvpn/easy-rsa/
    fi
    # Get easy-rsa
    wget -O ~/EasyRSA-3.0.1.tgz https://github.com/OpenVPN/easy-rsa/releases/download/3.0.1/EasyRSA-3.0.1.tgz
    tar xzf ~/EasyRSA-3.0.1.tgz -C ~/
    mv ~/EasyRSA-3.0.1/ /etc/openvpn/
    mv /etc/openvpn/EasyRSA-3.0.1/ /etc/openvpn/easy-rsa/
    chown -R root:root /etc/openvpn/easy-rsa/
    rm -rf ~/EasyRSA-3.0.1.tgz
    cd /etc/openvpn/easy-rsa/
    # Create the PKI, set up the CA, the DH params and the server + client certificates
    ./easyrsa init-pki
    ./easyrsa --batch build-ca nopass
    ./easyrsa gen-dh
    ./easyrsa build-server-full server nopass
    ./easyrsa build-client-full $CLIENT nopass
    ./easyrsa gen-crl
    # Move the stuff we need
    cp pki/ca.crt pki/private/ca.key pki/dh.pem pki/issued/server.crt pki/private/server.key /etc/openvpn/easy-rsa/pki/crl.pem /etc/openvpn
    # Generate server.conf
    echo "port $PORT
proto udp
dev tun
sndbuf 0
rcvbuf 0
ca ca.crt
cert server.crt
key server.key
dh dh.pem
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt" > /etc/openvpn/server.conf
    echo 'push "redirect-gateway def1 bypass-dhcp"' >> /etc/openvpn/server.conf
    # DNS
    case $DNS in
        1)
        # Obtain the resolvers from resolv.conf and use them for OpenVPN
        grep -v '#' /etc/resolv.conf | grep 'nameserver' | grep -E -o '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' | while read line; do
            echo "push \"dhcp-option DNS $line\"" >> /etc/openvpn/server.conf
        done
        ;;
        2)
        echo 'push "dhcp-option DNS 8.8.8.8"' >> /etc/openvpn/server.conf
        echo 'push "dhcp-option DNS 8.8.4.4"' >> /etc/openvpn/server.conf
        ;;
        3)
        echo 'push "dhcp-option DNS 208.67.222.222"' >> /etc/openvpn/server.conf
        echo 'push "dhcp-option DNS 208.67.220.220"' >> /etc/openvpn/server.conf
        ;;
        4)
        echo 'push "dhcp-option DNS 129.250.35.250"' >> /etc/openvpn/server.conf
        echo 'push "dhcp-option DNS 129.250.35.251"' >> /etc/openvpn/server.conf
        ;;
        5)
        echo 'push "dhcp-option DNS 74.82.42.42"' >> /etc/openvpn/server.conf
        ;;
    esac
    echo "keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3
crl-verify crl.pem" >> /etc/openvpn/server.conf
    # Enable net.ipv4.ip_forward for the system
    if [[ "$OS" = 'debian' ]]; then
        sed -i 's|#net.ipv4.ip_forward=1|net.ipv4.ip_forward=1|' /etc/sysctl.conf
    else
        # CentOS 5 and 6
        sed -i 's|net.ipv4.ip_forward = 0|net.ipv4.ip_forward = 1|' /etc/sysctl.conf
        # CentOS 7
        if ! grep -q "net.ipv4.ip_forward=1" "/etc/sysctl.conf"; then
            echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf
        fi
    fi
    # Avoid an unneeded reboot
    echo 1 > /proc/sys/net/ipv4/ip_forward
    # Set NAT for the VPN subnet
    iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j SNAT --to $IP
    sed -i "1 a\iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j SNAT --to $IP" $RCLOCAL
    if pgrep firewalld; then
        # We don't use --add-service=openvpn because that would only work with
        # the default port. Using both permanent and not permanent rules to
        # avoid a firewalld reload.
        firewall-cmd --zone=public --add-port=$PORT/udp
        firewall-cmd --zone=trusted --add-source=10.8.0.0/24
        firewall-cmd --permanent --zone=public --add-port=$PORT/udp
        firewall-cmd --permanent --zone=trusted --add-source=10.8.0.0/24
    fi
    if iptables -L | grep -qE 'REJECT|DROP'; then
        # If iptables has at least one REJECT rule, we asume this is needed.
        # Not the best approach but I can't think of other and this shouldn't
        # cause problems.
        iptables -I INPUT -p udp --dport $PORT -j ACCEPT
        iptables -I FORWARD -s 10.8.0.0/24 -j ACCEPT
        iptables -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
        sed -i "1 a\iptables -I INPUT -p udp --dport $PORT -j ACCEPT" $RCLOCAL
        sed -i "1 a\iptables -I FORWARD -s 10.8.0.0/24 -j ACCEPT" $RCLOCAL
        sed -i "1 a\iptables -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT" $RCLOCAL
    fi
    # If SELinux is enabled and a custom port was selected, we need this
    if which sestatus; then
        if sestatus | grep "Current mode" | grep -qs "enforcing"; then
            if [[ "$PORT" != '1194' ]]; then
                # semanage isn't available in CentOS 6 by default
                if ! which semanage > /dev/null 2>&1; then
                    yum install policycoreutils-python -y
                fi
                semanage port -a -t openvpn_port_t -p udp $PORT
            fi
        fi
    fi
    # And finally, restart OpenVPN
    if [[ "$OS" = 'debian' ]]; then
        # Little hack to check for systemd
        if pgrep systemd-journal; then
            systemctl restart openvpn@server.service
        else
            /etc/init.d/openvpn restart
        fi
    else
        if pgrep systemd-journal; then
            systemctl restart openvpn@server.service
            systemctl enable openvpn@server.service
        else
            service openvpn restart
            chkconfig openvpn on
        fi
    fi
    # Try to detect a NATed connection and ask about it to potential LowEndSpirit users
    EXTERNALIP=$(wget -qO- ipv4.icanhazip.com)
    if [[ "$IP" != "$EXTERNALIP" ]]; then
        echo ""
        echo "Looks like your server is behind a NAT!"
        echo ""
        echo "If your server is NATed (e.g. LowEndSpirit), I need to know the external IP"
        echo "If that's not the case, just ignore this and leave the next field blank"
        read -p "External IP: " -e USEREXTERNALIP
        if [[ "$USEREXTERNALIP" != "" ]]; then
            IP=$USEREXTERNALIP
        fi
    fi
    # client-common.txt is created so we have a template to add further users later
    echo "client
dev tun
proto udp
sndbuf 0
rcvbuf 0
remote $IP $PORT
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
comp-lzo
verb 3" > /etc/openvpn/client-common.txt
    # Generates the custom client.ovpn
    newclient "$CLIENT"
    echo ""
    echo "Finished!"
    echo ""
    echo "Your client config is available at ~/$CLIENT.ovpn"
    echo "If you want to add more clients, you simply need to run this script another time!"
fi

4.10. Créer un tunnel SSL avec Stunnel

https://www.stunnel.org/howto.html

4.11. Créer un tunnel SSL avec Ncat

https://nmap.org/ncat/guide/ncat-ssl.html

4.12. Dépasser les pare-feux avec HTTPS/TLS/TCP443

4.13. Placer du trafic Tor à travers un pare-feu à travers TCP443

L'objectif est de vérifier le pays de la connexion originale et celui d'une connexion Tor. L'outil torsocks place le trafic TCP (TCP80 dans cet exemple) sur le port TCP 9080 du proxy qui l'adresse à un noeud Tor disponible sur les ports TCP80 ou TCP443.

Installation des outils tor et curl.

apt-get install tor curl -y

On peut forcer des passerelles utilisant les ports TCP80 et TCP443.

echo "ReachableAddresses *:80,*:443" >> /etc/tor/torrc
echo "ReachableAddresses reject *:*" >> /etc/tor/torrc
systemctl restart tor

Récupération des informations de la connexion originale.

curl ipinfo.io/country
  FR

Récupération des informations de la connexion Tor.

torsocks curl ipinfo.io/country
RO

Vérifier les connexions utilisées.

ss -antp | grep tor
LISTEN     0      128               127.0.0.1:9050                     *:*      users:(("tor",pid=2327,fd=7))
ESTAB      0      0            192.168.122.54:37037          23.xx.xx.90:443    users:(("tor",pid=2327,fd=11))
ESTAB      0      0            192.168.122.54:33434          31.xx.xx.47:443    users:(("tor",pid=2327,fd=4))

Attention, uniquement le trafic de la commande curl en TCP est placé dans le tunnel Tor.

4.14. Héberger un site en .onion (Tor) avec Apache

Références

results matching ""

    No results matching ""