​​Installation du serveur LDP AV
​​Revenir sur ​+Base de connaissance AV​
​​ 

​
​Objectifs de ce PAD

  • ​​L'objectif est d'ajouter à ce serveur une deuxième instance de serveur LDP, mais cette fois en utilisant rwwplay.
  • ​​Documenter l'administration du serveur (arrêt et démarrage des process, scripts...)
  • ​​Ensuite, d'exposer l'interface LDP sur l'adresse : 
  • ​​Enfin, d'héberger la carto PAIR sur le site de l'AV et de la faire pointer principalement sur ce serveur.
​​ 

​
​Reste à faire

  • ​​Mettre un script (crontab), qui vérifie la présence de ce processus  (qui n'aura pas toujours le même PID), et qui le relance s'il tombe...
  • ​​Et un script plus simple pour lancer le serveur...
​​ 

​
​Comment démarrer le serveur

​​(Je note cela en haut du PAD pour plus de facilité d'accès...)
​
​Se connecter sur le serveur LDP AV :
​​ 
​
​Démarrer le serveur rwwplay :
​​cd ~/rwweb-0.7.2-SNAPSHOT/
​​Avec utilisation du certificat SSL:
​​bin/rwweb -Dhttp.port=9001 -Dhttps.port=8443 -Dhttps.keyStore=/home/av/letsencrypt/AV/keystore.jks -Dhttps.keyStorePassword=123Soleil! -Drww.root.container.path=/home/av/ldpwww -Dhttp.hostname=ldp.virtual-assembly.org &
​​ 
​​Sans (utile pour debug):
​​bin/rwweb -Dhttp.port=9001 -Dhttps.port=8443 -Dhttps.trustStore=noCA -Drww.root.container.path=/home/av/ldpwww -Dhttp.hostname=ldp.virtual-assembly.org &
​​ 
​​Tentative d'utiliser -Dname=RwwPlay comme argument dans la commande de lancement pour être sur de son identité ? ----> Ne fonctionne pas, nous avons toujours "java" comme nom du processus.
​​ 

​
​Comment arrêter le serveur

​​sudo kill sudo lsof -t -i:9001​ 
​​ 
​​sudo kill -9 | sudo lsof -t -i:9001
​​ 
  • ​​Attention : il se peut que le serveur ne se soit pas arrêté correctement. Dans ce cas, il peut y avoir un fichier RUNNING_PID présent dans le répertoire d'éxécution. Supprimez-le.
​​rm ~/rwweb-0.7.2-SNAPSHOT/RUNNING_PID
​​ 

​
​Comment savoir que le serveur rwwplay est UP ou DOWN lorsqu'on se connecte ?

​​sudo netstat -tulpn | grep 9001
​​ 
​​av@c1-10-1-34-165:~/rwweb-0.7.2-SNAPSHOT$ sudo netstat -tulpn | grep 9001
​​tcp6       0      0 :::9001                 :::*          LISTEN      493/java    
​​ 
​​A distance, on peut aussi regarder l'url : 
​​(parfois faire deux accès successifs pour que cela fonctionne...)
​​ 

​
​Mise en conditions opérationnelle du serveur LDP AV

​​ 
​
​1er test : En ajoutant un "&" à la fin de la commande
​​Cela créer un processus avec un PID = 28926 (par exemple)
​​ 
​​ 
​​Si après ça, je quitte avec Ctrl+C, que je tente d'accéder à https://ldp.virtual-assembly.org:8443/
​​ 
​​On retrouve le processus actif (voir en bas de la commande top ci-dessous)
​​av@c1-10-1-34-165:~/rwweb-0.7.2-SNAPSHOT$ top
​​ 
​​top - 10:16:31 up 238 days, 19:37,  1 user,  load average: 3.00, 3.40, 3.32
​​Tasks:  72 total,   1 running,  71 sleeping,   0 stopped,   0 zombie
​​%Cpu(s):  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
​​KiB Mem:   2072392 total,  1395764 used,   676628 free,   135572 buffers
​​KiB Swap:        0 total,        0 used,        0 free.   582204 cached Mem
​​top - 10:16:34 up 238 days, 19:38,  1 user,  load average: 3.00, 3.39, 3.32
​​  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                           
​​%Cpu(s):  6.7 us,  0.1 sy,  0.0 ni, 93.2 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
​​KiB Mem:   2072392 total,  1402460 used,   669932 free,   135572 buffers
​​30673 jmv       20   0  391524 196940  13516 S   0.3  9.5  21:18.58 java          
​​    2 root      20   0       0      0      0 S   0.0  0.0   0:00.01 kthreadd      
​​28926 av        20   0 1282080  88684  12720 S  28.5  4.3   0:05.98 java                                              
​​Si je quitte ma session shell, le processus est encore là, cool !
​​ 
​​Sinon, Pierre_PP propose d'utiliser Screen : https://doc.ubuntu-fr.org/screen
​​Mais je ne crois pas que ce soit adapté.
​​ 

​
​Historique

​​Jean-marc a acheté il y a quelques mois un serveur pour y installer Semantic Forms pour l'AV.
​​@JM, je te laisse compléter l'historique si tu veux...
​​ 
​​Mail de JM le 02/11/2015 : 
​​ 
​​jmv@c1-10-1-34-165:~$ cat /etc/passwd | grep av
​​av:x :1003:1003:Equipe AV - Yannick Benoit JMV,,06 16 43 12 69,02 43 75 24 45:/home/av:/bin/bash
​​ 
​​Pour info j'ai fait ainsi:
​​sudo adduser av
​​sudo adduser av sudo
​​ 
​​Je "revendique" les ports
  • ​​9000 pour semforms pour av
  • ​​9153 pour une application pour un client
  • ​​9111 pour un sandbox semforms
  • ​​9222 pour une application familiale
  • ​​9333 pour projets à venir
​​ 
​​Tenez moi au courant de ce que vous prenez comme ports et installez comme packages .
​​A noter que zenmap est une excellente application pour savoir quels ports sont utilisés et + encore .
​​ 
​​Sans GUI et plus concis: 
​​sudo netstat -tulpn | grep LISTEN
​​ 
​​ 

​
​Installation du 2/11/2015 

​​ 
​​JM nous a envoyé les codes pour nous connecter et nous a ajouté un utilisateur AV.
​​ 
​​mdp : demander à Benoît ou Yannick ou JM.
​​Bienvenue du côté obscure... :)
​​ 
​
​Prérequis : 
  • ​​Git installé (c'est mieux pour la suite) : ok
  • ​​Java 8 installé : vérifier si la version 1.7 est ok pour rwwplay...
​​java - version
​​java version "1.7.0_65"
​​OpenJDK Runtime Environment (IcedTea 2.5.3) (7u71-2.5.3-0ubuntu0.14.04.1)
​​OpenJDK Zero VM (build 24.65-b04, mixed mode)
​​ 
​
​Installation de rwwplay
​​Lien vers le site de Sylvain, contenant une version de rwwplay avec un CORS bien configuré.
​​ 
​​Création du répertoire du binaire de rwwplay
​​mkdir install
​​cd install
​​unzip rwweb-0.7.2-SNAPSHOT.zip
​​mv rwweb-0.7.2-SNAPSHOT.zip ../
​​ 
​​Création du répertoire de la "base de donnée" (même sous forme de répertoire) de rwwplay
​​tar -xzf ldpwww.tar.gz
​​mv ldpwww ../
​​ 
​​Lancement du serveur rwwplay
​​cd rwweb-0.7.2-SNAPSHOT/
​​bin/rwweb -Dhttps.port=8443 -Dhttps.trustStore=noCA -Drww.root.container.path=/home/av/ldpwww
​​ 
​​ 
​​Résumé de l'erreur : fatal error: caught unhandled signal 11
​​ 
​​Comment modifier le port sur lequel se lance rwwplay ? sachant que lorsqu'il se lance, il prend le port 9000 que JM utilise déjà pour SemanticForms
​​ 
​​Ici ce que je vois sur mon PC :
​​ 
​​ 
​
​Modification des ports
​​JM nous suggère de lire ceci :
​​En effet, sous Semantic Forms, qui se lance avec la commande "run", il suffit de faire "run <nouveau port>" et ça fonctionne. Mais dans le cas de rwwplay, il se lance différemment.
​​ 
​​JM voulait au début modifier les ports de lancement de Semantic Forms, mais pour des raisons d'administration de son serveur, c'était compliqué.
​​ 
​​ 
​​En fait, l'erreur venait de la version de Java, qui n'était pas en 1.8.
​​ 
​
​Utilisation d'une JDK 1.8 (à la place de 1.7)
​​ 
​​ln -s /home/jmv/apps/jdk $HOME/jdk
​​ 
​​//Modification du fichier ~/.bashrc  avec : 
​​ 
​​export JAVA_HOME=$HOME/jdk
​​export PATH=$HOME/bin:$JAVA_HOME/bin:$PATH
​​ 
​​Explication de JM, car jdk est un lien chez lui vers la bonne version 1.8.
​​ls -ld ~/apps/jdk*
​​lrwxrwxrwx 1 jmv jmv       11 août   6 10:44 /home/jmv/apps/jdk -> jdk1.8.0_51
​​drwxrwxr-x 8 jmv jmv     4096 oct.  28  2014 /home/jmv/apps/jdk1.8.0_06
​​drwxrwxr-x 8 jmv jmv     4096 août   6 10:43 /home/jmv/apps/jdk1.8.0_51
​​ 
​​Je viens de vérifier que les permissions sont bonnes pour toi dans ~jmv/apps/jdk/jdk1.8.0_51
​​ 
​​Résultat : ca fonctionne !
​​ 
​​av@c1-10-1-34-165:~$ java -version
​​java version "1.8.0_51"
​​Java(TM) SE Runtime Environment (build 1.8.0_51-b07)
​​Java HotSpot(TM) Client VM (build 25.51-b07, mixed mode)
​​ 

​
​Redirection depuis le domaine virtual-assembly.org

​​ 
​​La redirection depuis https://ldp.virtual-assembly.org:8443/  vers  https://212.47.232.171:8443/  fonctionne, sauf qu'on lance le serveur pour écouter soit sur l'IP soit sur le domaine. Il ne peut pas répondre aux deux à la fois (ou alors il manque un paramétrage)
​​ 
​​Mis en prod le 18/12/2015 : ok
​​ 

​
​Ajout d'un container pour la carto PAIR

​​ 
​​En attendant que la fonction createContainer() fonctionne, nous créons le répertoire "cartopair" et relançons le serveur.
​​ 
​​cd ~/ldpwww
​​cp -r todos/ cartopair/
​​ 
​​Relance du serveur
​
​Problème initial: 
  • ​​Impossible de requêter un objet copié dans le container ni de créer un objet en plus dedans
​
​Raison:
  • ​​le fichier .acl.ttl initialement présent (qui définit les droits d'accès) fait officiellement référence à l'IP locale (localhost:8443)
  • ​​pour autoriser l'accès au container depuis l'extérieur, il faut remplacer cette référence par le nom de domaine ou l'IP publique que nous souhaitons utiliser.
​​ 
​​ @prefix acl: <http://www.w3.org/ns/auth/acl#> .
​​@prefix foaf: <http://xmlns.com/foaf/0.1/> .
​​
​​[] acl:accessToClass [ acl:regex "https://(\\w+\\.)?ldp.virtual-assembly.org:8443/.*[.]acl" ];
​​   acl:mode acl:Read;
​​   acl:agentClass foaf:Agent .
​​
​​
​​[] acl:accessToClass [ acl:regex "https://(\\w+\\.)?ldp.virtual-assembly.org:8443/.*" ];
​​   acl:mode acl:Write, acl:Read, acl:Append;
​​   acl:agentClass foaf:Agent .
​​
​​#if you name your computer "bleau" in /etc/hosts then it is easier to debug virtual cell phone apps
​​#for Android for example: http://www.bradcurtis.com/hosts-files-and-the-google-android-emulator/
​​[] acl:accessToClass [ acl:regex "https://(\\w+\\.)?bleau:8443/.*" ];
​​   acl:mode acl:Read, acl:Write;
​​   acl:agent <card#i> .

​
​Test de la carto PAIR sur ce nouveau serveur LDP

​​ 
​​Pour enregistrer un triplet sur le serveur : 
​​ 
​​var store = new MyStore({ container : "https://ldp.virtual-assembly.org:8443/2013/cartopair/",
​​                       context : "http://owl.openinitiative.com/oicontext.jsonld",
​​                       template : "",
​​                       partials : ""})
​​ 
​​  var jsonLd = {
​​    "@context":{
​​    },
​​    "@type" : "av:Organization"
​​  }
​​  store.save(jsonLd);
​​ 
​
​Attention ! Ne pas déposer des fichiers d'un serveur à un autre, cela ne fonctionne pas, il manque un lien !
​​ 
​
​GET sur un container 
​​store.get("https://ldp.virtual-assembly.org:8443/2013/cartopair/b3af65a422").then(console.log.bind(console))
​​ 

​
​Comment voir les fichiers sur le serveur depuis l'extérieur ?

​​Tapper dans votre navigateur :
​​ 
​​ 

​
​Peut-on fonctionner en HTTP sur le port 9001

​​ 
​​Pour éviter d'avoir à créer un certificat pour le serveur, nous avons testé l'accès via le port 9001.
​​ 
​​Nous avons arrêté le serveur proprement, modifié le fichier .acl.ttl du container cartopair pour qu'il point sur 9001 (http).
​​Le serveur démarre bien, mais lorsque nous souhaitons accéder à un container via 9001, http://ldp.virtual-assembly.org:9001/2013/cartopair/
​​No SSLHandler!
​​javax.net.ssl.SSLException: No SSLHandler!
​​ 
​​Conclusion : le serveur a vraiment besoin de tourner sur https. Nous allons donc créer un certificat SSL...

​
​Ajout d'un certificat SSL serveur

​​ 
​​Après discussion avec Benoit, nous deux ne sommes pas forcément des spécialistes dans ce domaine. Un mail a été envoyé à JM. En attendant on teste des choses...
​​ 
​
​Liens externes
​​ 
​​sudo apt-get install openssl
​​Déjà installé
​​ 
​
​Création de la clé privée
​​Créer un fichier server.key, qui est la clé privée.
​​ 
​​av@c1-10-1-34-165:/etc/ssl$ cd /etc/ssl
​​av@c1-10-1-34-165:/etc/ssl$ sudo mkdir tmp
​​av@c1-10-1-34-165:/etc/ssl$ cd tmp
​​av@c1-10-1-34-165:/etc/ssl$ sudo openssl genrsa -out server.key 2048
​​Generating RSA private key, 2048 bit long modulus
​​.....................................................+++
​​............+++
​​e is 65537 (0x10001)
​​ 
​​Ensuite il faut générer un fichier de « demande de signature de certificat », en anglais CSR : Certificate Signing Request  : 
​​ 
​​av@c1-10-1-34-165:/etc/ssl/tmp$ sudo openssl req -new -key server.key -out server_v-a.csr
​​[sudo] password for av: 
​​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) [AU]:FR
​​State or Province Name (full name) [Some-State]:Ile de france
​​Locality Name (eg, city) []:Paris
​​Organization Name (eg, company) [Internet Widgits Pty Ltd]:Assemblée Virtuelle
​​Organizational Unit Name (eg, section) []:AV
​​Common Name (e.g. server FQDN or YOUR name) []:virtual-assembly.org
​​Email Address []:webmaster@virtual-assembly.org
​​ 
​​Please enter the following 'extra' attributes
​​to be sent with your certificate request
​​A challenge password []:toto
​​An optional company name []:Practishare
​​ 
​​Cela créer le fichier server_a-v.csr dans le rép. tmp
​​Ce fichier correspond à la demande de certificat qu'il faudra fournir au site plus bas.
​​ 
​
​Génération du certificat :
​​Pour générer un certificat reconnu par une AC (Autorité de certification), on peut aller sur un site qui propose des certificats valides pour 6 mois gratuitement.
​​ 
​​J'ai dû créé un compte avec l'adresse yannick.duthe@assemble-virtuelle.org
​​(pour le mot de passe, je ne le partage pas, désolé ;-) )
​​ 
​​ 
​​Ensuite, j'ai ajouté un email : contact@assemblee-virtuelle.org
​​ 
​​Ensuite,  un domaine : virtual-assembly.org, qui a été vérifié par l'email :  webmaster@virtual-assembly.org utilisé dans la demande (créé pour l'occasion par Guillaume).
​​ 
​​ 
​​Le site a bien accepté et nous a retourné un CA : 
​​ 
​​-----BEGIN CERTIFICATE-----
​​MIIFHDCCAwSgAwIBAgIDEYzOMA0GCSqGSIb3DQEBCwUAMHkxEDAOBgNVBAoTB1Jv
​​b3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
​​Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9y
​​dEBjYWNlcnQub3JnMB4XDTE1MTIyMTIwNDQ0NFoXDTE2MDYxODIwNDQ0NFowHzEd
​​MBsGA1UEAxMUdmlydHVhbC1hc3NlbWJseS5vcmcwggEiMA0GCSqGSIb3DQEBAQUA
​​A4IBDwAwggEKAoIBAQDPAuBrUe8Tr4IxkyOheTNkd4TvKyAbdUHDZh9XKJjnufss
​​BK9PDo98ltyFvmbwyZEYD+1JTob1I42r2O94nVcNbI3zwvAOuB7CcPfYNmWJKxKq
​​SI5Btq9xAXTgq7b2MSFLB/MnJAG7bN9j88zDEVZnq/SPws9ZowP7ZwDCQGQy+t2X
​​mqxwpez3SpNZa2L+0/PkoOLTNYpOrXqtrdRZmV3LdxFn9JdBnd+ZKxZ3l9bxN5m4
​​VuOcN3rElNwupX02dkwnRhUEu95XNOFiXEz7gMno1ff3ztsuPWRRMRGBSaKd5Nr7
​​Vce5/4KgO7X12xITBtU04IjGhKU+AyBnFEMlR2upAgMBAAGjggEFMIIBATAMBgNV
​​HRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIDqDA0BgNVHSUELTArBggrBgEFBQcDAgYI
​​KwYBBQUHAwEGCWCGSAGG+EIEAQYKKwYBBAGCNwoDAzAzBggrBgEFBQcBAQQnMCUw
​​IwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLmNhY2VydC5vcmcvMDEGA1UdHwQqMCgw
​​JqAkoCKGIGh0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMEMGA1UdEQQ8
​​MDqCFHZpcnR1YWwtYXNzZW1ibHkub3JnoCIGCCsGAQUFBwgFoBYMFHZpcnR1YWwt
​​YXNzZW1ibHkub3JnMA0GCSqGSIb3DQEBCwUAA4ICAQBE+dTY7LyFW6nG/YjZtsOa
​​S4EuwDUBaPK/qYZilyB/yqNeegJ7OhibDNvX1EfoMAx74DEwuc1R4QTfLdZuTuon
​​S//wAzjjEmlteU8jK73er61UpHAq1q04y9jSIHlGlXolzQ4EFTrqsRg+U1Ex4fgl
​​3kcBEbpyfVUA7wcafsjHLx9dpNBTEgNN0HImBp2jlgLlFkDJVcuRw4qenkSjNw6I
​​85/P6azV8lZtZQwA/cV+yjlqhmZf5Yjp6xVivhtcsNMPpFTHn5exHtF7SfPrAi7P
​​FoWguBH/2Ofq+OFOIxnHTwUdXN/4aeOkNbSq1/cm62ywIAgFRT6eW5TnQLGg2mqq
​​xn57xs0/WQADgZRXJYD2oZniYIMEidyRXHPHDuXYLP8f5nrxw2JjYfeULK8epztM
​​oidPdXvRViTCGmE7m/SRsDxzcIfoMMSILvUGucOkPP7rz4c6rHPflx2lY5T0Csny
​​zR77ka/k12MjbRZHUWADewlasB3EYzg1Cb47e2CLn2AlgXaOVPyKF0daMFdaI8Dm
​​mfh+ZShFxExAQV6XSyXCCYiII7h5FF+i8B0BhAZ0OSseC5QKWiZlDDujS9Y6FhkA
​​RW9eIVOt00h6MbUbRTbcf59S0psbmEAkx8osxtwYIW/RVOBXvmYxV7G1ClpUnA+f
​​OFj7IPAv1VtXcKYJBxLD/w==
​​-----END CERTIFICATE-----
​​ 
​​Que j'ai recopié dans un fichier appelé server_v-a.crt
​​ 
​
​Lancement de rwwplay en précisant le certificat
​​Or, dans la commande pour lancer le serveur, nous avons :
​​bin/rwweb -Dhttps.port=8443 -Dhttps.trustStore=noCA
​​ 
​​J'ai donc copié le certificat dans le rép de lancement de rwwplay.
​​ 
​​sudo kill sudo lsof -t -i:9001​ 
​​sudo netstat -tulpn | grep 9001
​​ 
​​bin/rwweb -Dhttp.port=9001 -Dhttps.port=8443 -Dhttps.trustStore=server_v-a.crt -Drww.root.container.path=/home/av/ldpwww -Dhttp.hostname=ldp.virtual-assembly.org &
​​ 
​​Ce qui ne change rien au problème.
​​Bref, le fichier est stocké ici : /etc/ssl/tmp/server_v-a.crt
​​ 
​​ 

​
​Discussion avec JM : 

​​A priori, il ne faut laisser dans le certificat uniquement : ldp.virtual-assembly.org, sans préciser "https", ni "8443"
​​ 

​
​Discussion avec Sylvain

​​Qui nous conseille d'aller voir dans le wiki de rwwplay
​​Mais je n'ai pas trouvé grand chose...
​​ 

​
​Tentative de modification du fichier de conf dans conf/application.conf

​​ 
​​# This is the main configuration file for the application.
​​# ~~~~~
​​ 
​​# RWW Play Apps setup
​​# ===================
​​#
​​# RWW Play contains a number of apps, some of which are optional
​​ 
​​http.hostname=ldp.virtual-assembly.org
​​https.port=8443
​​https.trustStore="/etc/ssl/tmp/server_v-a.crt"
​​ 
​​# enable Subdomain support 
​​rww.subdomains=true //default:false
​​ 
​​Je pensais que si on remplissait ça, cela nous permettait de ne pas mettre ces paramètres au lancement de rwwplay, mais en fait il ne les utilise pas :(
​​ 
​​ 

​
​Tests

​​ 
​​Retirer l'exception de sécurité dans Firefox...
​​ 
​​ 
​​Le certificat reste celui de Mavericks : localhost... bref, comme si le certificat passé en paramètre n'était pas fourni...
​​ 
​​ 

​
​Discussion avec Henry

​​(voir mails)
​​ 
​​ 
​​"https.keyStore - The path to the keystore containing the private key and certificate, if not provided generates a keystore for you"
​​ 
  • ​​https.keyStoreType - The key store type, defaults to JKS
​​ 
​​Il faut donc comprendre la notion de JKS, qui demande un mot de passe
​​Pour cela, tout est décrit ici : 
​​ 
​​Un outil "KeyTools" permet de faire pleins de truc cool :)
​​ 
​​Voir la partie "Generate Certificates for an SSL Server"
​​ 
​​Voir aussi sur la doc d'oracle : 
​​Notamment la partie :
​
​Importing a Certificate for the CA
​​ 

​
​Ce que je comprends (Yannick)

​​ 
​​En effet, il ne faut pas confondre le certificat CA et le "magasin de certificat".
​​Dans le cas de rwwplay, il utilise par défaut le magasin de certificat de la JRE.
​​C'est pour cette raison qu'il faut importer le certificat créé par CACert (voir plus haut) dans le magasin de certificat de la JRE, en  utilisant l'outil KeyTool.
​​ 
​
​Autres doc à propos du keystore
​​ 
​​Ils disent qu'on doit avoir un certif root, un intermédiaire et un primaire... mais nous n'avons pas tout ça...
​​Pour le root, voir ici : https://www.cacert.org/index.php?id=3
​​ 
​​Récupération des certificats en local sur la machine : 
​​yannick@logthree:~/Téléchargements$ scp cacert* av@212.47.232.171:/home/av
​​av@212.47.232.171's password: 
​​cacert_int.crt                                                                                              100% 2610     2.6KB/s   00:00    
​​cacert_root.crt                                                                                             100% 2569     2.5KB/s   00:00    
​​ 
​​ 
​​Finalement, suite à la discussion avec Henry et avec un Hacker sur le Mans, il est préférable de créer des certificats via letsencrypt, pour qu'ils soient acceptés aussi par les navigateurs Windows (IE, Edge), ce que ne permet pas des certificats créés par CACert.
​​ 

​
​Création d'un certificat serveur sur Let's encrypt

​​ 
​​Se mettre sur le serveur
​​ 
​​$ cd letsencrypt
​​$ ./letsencrypt-auto --help
​​ 
​​Vérifier que le port 80 est libre
​​ 
​​./letsencrypt-auto certonly --standalone -d ldp.virtual-assembly.org
​​ 
​​Cela monte un serveur web sur le port 80
​​ 
​​Le programme crée une chaine de certificat *.pem dans le répertoire : 
​​/etc/letsencrypt/archive/ldp.virtual-assembly.org/ (pour y accéder, passer en sudo -s, exceptionnellement...)
​​ 
​​Les fichiers générés sont : 
  • ​​cert1.pem
  • ​​chain1.pem
  • ​​fullchain1.pem
  • ​​privkey1.pem
​​ 
​​Pour voir à quoi correspondent les fichiers générés : 
​​ 
​​Pour convertir un .pem en .crt :
​​ 
​​Nous allons utiliser "fullchain1.pem", qui est notre certificat serveur contenant en lui toute la chaine de confiance (semble-t-il...).
​​ 
​​A présent, il faut créer un keystore (container de certificat) pour la JRE.
​​ 
​​cat fullchain1.pem privkey1.pem | openssl pkcs12 -export -out cert.p1
​​Error : unable to load certificates
​​Pas d'aide sur cette erreur... peut-être que nous n'avons pas le droits de créer dans ce répertoire tout simplement...
​​ 
​​Copie des certificats dans le répertoie ~/letsencrypt/AV/, lancement de la même commande, cela ne change rien, toujours le même message...
​​ 

​
​Création du keystore JKS (magasin de certificat Java)

​​ 
​​ 
​​root@c1-10-1-34-165:~/letsencrypt/AV# keytool -genkey -alias ldp.virtual-assembly.org -keyalg RSA -keystore keystore.jks
​​Enter keystore password:  
​​Re-enter new password: 
​​What is your first and last name?
​​  [Unknown]:  Yannick DUTHE
​​What is the name of your organizational unit?
​​  [Unknown]:  Assemblée Virtuelle
​​What is the name of your organization?
​​  [Unknown]:  AV
​​What is the name of your City or Locality?
​​  [Unknown]:  Paris
​​What is the name of your State or Province?
​​  [Unknown]:  France
​​What is the two-letter country code for this unit?
​​  [Unknown]:  FR
​​Is CN=Yannick DUTHE, OU=Assemblée Virtuelle, O=AV, L=Paris, ST=France, C=FR correct?
​​  [no]:  yes
​​ 
​​Enter key password for <ldp.virtual-assembly.org>
​​    (RETURN if same as keystore password):  
​​ 
​​Nous avons donc un keystore.jks, avec un mot de passe : ...
​​ 
​​A présent, il faut ajouter notre certificat .PEM à ce keystore.jks
​​ 
​​root@c1-10-1-34-165:~/letsencrypt/AV# keytool -import -trustcacerts -alias root -file fullchain1.crt -keystore keystore.jks
​​Enter keystore password:  
​​Owner: CN=ldp.virtual-assembly.org
​​Issuer: CN=Let's Encrypt Authority X1, O=Let's Encrypt, C=US
​​Serial number: 1933c52e7f2e2fa11cdfcbd3e580c9ed615
​​Valid from: Tue Jan 05 17:51:00 UTC 2016 until: Mon Apr 04 17:51:00 UTC 2016
​​Certificate fingerprints:
​​     MD5:  9B:14:CE:C4:07:59:AC:8D:31:AD:B8:9E:BB:5F:6D:84
​​     SHA1: 77:7D:AC:45:46:91:FA:17:56:23:B3:7B:ED:32:9A:ED:63:51:3E:74
​​     SHA256: 00:C0:8B:1C:BB:4C:7C:A4:89:E0:3D:BB:22:E0💿7B:10:A8:30:FE:4A:11:7C:22:37:B2:32:12:77:E1:D7:AB
​​     Signature algorithm name: SHA256withRSA
​​     Version: 3
​​...
​​Trust this certificate? [no]:  yes
​​Certificate was added to keystore
​​ 
​​C'est parti, maintenant, relançons le serveur avec ce keystore.
​​ 
​​sudo kill sudo lsof -t -i:9001​ 
​​sudo netstat -tulpn | grep 9001
​​cd ~/rwweb-0.7.2-SNAPSHOT/
​​bin/rwweb -Dhttp.port=9001 -Dhttps.port=8443 -Dhttps.keyStore=/home/av/letsencrypt/AV/keystore.jks -Dhttps.keyStorePassword=123Soleil! -Drww.root.container.path=/home/av/ldpwww -Dhttp.hostname=ldp.virtual-assembly.org &
​​ 
​​Attention à bien utiliser "keyStore" et non "trustStore" comme nous avions l'habitude avant !
​​ 
​​ 

​
​Nouveaux tests du 18/01/2016

​​ 
​​Pour supprimer les certificats existants dans le keystore : 
​​keytool -delete -alias ldp.virtual-assembly.org -keystore keystore.jks
​​ 
​​Pour regarder ce qu'il y a dans le keystore : 
​​keytool -list -v -keystore keystore.jks
​​ 
​​ 
​
​Nouveau test avec le certificat CACert
​​Vidage du keytools
​​Import du root : 
​​keytool -import -trustcacerts -alias root -file cacert_root.crt -keystore keystore.jks
​​Import du certificat intermédiaire
​​keytool -import -trustcacerts -alias inter -file cacert_int.crt -keystore keystore.jks
​​Import du certificat
​​keytool -import -trustcacerts -alias cert -file server_v-a.crt -keystore keystore.jks
​​ 
​​ 
​​Le client rame et ne renvoit aucun message d'erreur...
​​Comme dans ce post : letsencrypt/letsencrypt#1701
​​ 
​​Ici, des outils pour tester le ssl : 
​​ 
​​Nous avons aussi essayé d'installer un tomcat, mais cette solution a été abandonnée.
​​ 
​
​Tentative pour Rwwplay:
​​openssl pkcs12 -export -in cert1.pem -inkey privkey1.pem -out cert_and_key_play.p12 -name rwwplay -CAfile fullchain1.pem -caname root
​​J'ai bien un fichier qui s'appelle cert_and_key_play.p12
​​ 
​​Creation du store:
​​keytool -importkeystore -deststorepass 123Soleil! -destkeypass 123Soleil! -destkeystore MyDSKeyStore.jks -srckeystore cert_and_key_play.p12 -srcstoretype PKCS12 -srcstorepass 123Soleil! -alias root
​​ 
​​Existing entry alias root exists, overwrite? [no]:  yes
​​keytool error: java.lang.Exception: Alias <root> does not exist
​​ 
​​Tentative de lancement de RwwPly suite a cette creation de store:
​​bin/rwweb -Dhttp.port=9001 -Dhttps.port=8443 -Dhttps.keyStore=/home/av/letsencrypt/AV/MyDSKeyStore.jks -Dhttps.keyStorePassword=123Soleil! -Drww.root.container.path=/home/av/ldpwww -Dhttp.hostname=ldp.virtual-assembly.org &
​​And It Works !
​​ 
​​Good game guys ;-)
​​ 

​
​Génération d'un nouveau certificat

​​ 
​​./letsencrypt-auto certonly --standalone -d ldp.virtual-assembly.org
​​ 
​​Le programme crée une chaine de certificat *.pem dans le répertoire : 
​​/etc/letsencrypt/archive/ldp.virtual-assembly.org/ (pour y accéder, passer en sudo -s, exceptionnellement...)
​​Les fichiers générés sont : 
  • ​​cert2.pem
  • ​​chain2.pem
  • ​​fullchain2.pem
  • ​​privkey2.pem
​​ 
​​Copie  des certificats dans le répertoire ~/letsencrypt/AV/
​​cp /etc/letsencrypt/archive/ldp.virtual-assembly.org/cert2.pem .
​​cp /etc/letsencrypt/archive/ldp.virtual-assembly.org/privkey2.pem .
​​ 
​​Pour convertir un .pem en .crt :
​​openssl x509 -outform der -in fullchain2.pem -out fullchain2.crt
​​ 
​​Création d'un P12 : 
​​openssl pkcs12 -export -in cert2.pem -inkey privkey2.pem -out cert_and_key_play2.p12 -name rwwplay -CAfile fullchain2.pem -caname root
​​ 
​​Création du store:
​​root@c1-10-1-34-165:~/letsencrypt/AV# keytool -importkeystore -deststorepass 123Soleil! -destkeypass 123Soleil! -destkeystore MyDSKeyStore2.jks -srckeystore cert_and_key_play2.p12 -srcstoretype PKCS12 -srcstorepass 123Soleil! -alias root
​​keytool error: java.lang.Exception: Alias <root> does not exist
​​ 
​​Erreur : le keystore n'a pas été créé, nous avons donc dupliqué le précédent... :)
​​ 
​​Pour regarder ce qu'il y a dans le keystore : 
​​keytool -list -v -keystore keystore.jks
​​ 
​​Arrêt du serveur : 
​​sudo kill sudo lsof -t -i:9001​ 
​​ 
​​Pour savoir s'il est bien arrêté :
​​sudo netstat -tulpn | grep 9001
​​ 
​​Lancement du serveur : 
​​cd rwweb-0.7.2-SNAPSHOT/
​​bin/rwweb -Dhttp.port=9001 -Dhttps.port=8443 -Dhttps.keyStore=/home/av/letsencrypt/AV/MyDSKeyStore2.jks -Dhttps.keyStorePassword=123Soleil! -Drww.root.container.path=/home/av/ldpwww -Dhttp.hostname=ldp.virtual-assembly.org &
​​ 

​
​Renouvellement du certificat

​​ 
​​Suite à la génération du certificat (voir première commande de la section passée) et aux conseils des collègues de Yannick, nous avons tenté de proprement ré-assigner ce nouveau certificat au KeyStore, afin de pouvoir l'utiliser dans nos applications.
​​ 
​​L'action se déroule dans le répertoire ~/letsencrypt/AV/ sur le serveur.
​​Après des essais amenant de la confusion d'utilisation du KeyStore MyDSKeyStore2.jks, nous avons décidé de basculer sur l'utilisation de keystore.jks, qui était vide.
​​ 
​​Les commandes utilisées:
​​keytool -list -v -keystore keystore.jks
​​Pour s'assurer qu'il n'y a rien dans le keystore, cette commande retourne:
​​Keystore type: JKS
​​Keystore provider: SUN
​​ 
​​Your keystore contains 0 entries
​​ 
​​Maintenant, basons-nous sur les commandes proposées par le collègue de Yannick, et let's go ! Première commande, permettant d'injecter le nouveau .p12 dans le keystore qui va bien:
​​keytool -importkeystore -v -srckeystore cert_and_key_play2.p12 -destkeystore keystore.jks -srcstoretype PKCS12 -deststoretype JKS -deststorepass 123Soleil! -srcstorepass 123Soleil!
​​ 
​​Cette commande nous retourne l'information de l'alias affecté au certificat, qui est "rwwplay" (pourquoi ?). Un petit list nous confirme que le certificat ayant cet alias est bien dispo.
​​Ensuite, pas envie de changer l'alias, donc tentons simplement de relancer rwwplay afin qu'il tape sur ce keystore:
​​cd rwweb-0.7.2-SNAPSHOT/
​​bin/rwweb -Dhttp.port=9001 -Dhttps.port=8443 -Dhttps.keyStore=/home/av/letsencrypt/AV/keystore.jks -Dhttps.keyStorePassword=123Soleil! -Drww.root.container.path=/home/av/ldpwww -Dhttp.hostname=ldp.virtual-assembly.org &
​​ 
​​Le serveur se lance correctement, puis un passage à l'URL https://ldp.virtual-assembly.org:8443 nous confirme que le certificat renouvelé est bien installé et valide (car compris par les navigateurs), et qu'il expirera le 26 Juin :
​​ 
​
​Pour le prochain renouvellement
​​ 
​​Suite à cette expérience, il faut retenir que les commandes à exécuter pour renouveler un certificat et le remplacer dans le JKS sont les suivantes:
​​ 
​​Attention ! NE PAS UTILISER LE MODE “CODE” de Paper, car si vous copiez-coller le texte ci-dessous dans une invite de commande, cela peut poser problème. En effet, les commandes ne passent plus, je pense qu’il y a un problème de caractères ajoutés par “paper”...
​​Une astuce est de le copier/coller dans un document intermédiaire de traitement de text (si possible un bloc note)
​​
​​ssh av@212.47.232.171
​​cd ~/letsencrypt/AV/
​​sudo ~/letsencrypt/letsencrypt-auto certonly --standalone -d ldp.virtual-assembly.org
  • ​​entrez le mot de passe de votre utilisateur sur le serveur
  • ​​(cela peut prendre plusieurs minutes et afficher un écran sur fond bleu)
​​sudo su
​​
​​->regarder ici le numéro (X) correspondant au nouveau certificat créé dans l'archive avec la commande : 
​​ls /etc/letsencrypt/archive/ldp.virtual-assembly.org/
​​
​​cp /etc/letsencrypt/archive/ldp.virtual-assembly.org/certX.pem .
​​cp /etc/letsencrypt/archive/ldp.virtual-assembly.org/privkeyX.pem .
​​cp /etc/letsencrypt/archive/ldp.virtual-assembly.org/fullchainX.pem .
​​openssl x509 -outform der -in fullchainX.pem -out fullchainX.crt
​​openssl pkcs12 -export -in fullchainX.pem -inkey privkeyX.pem -out cert_and_key_playX.p12 -name ldp.virtual-assembly.org -CAfile fullchainX.pem -caname root
  • ​​entrez le mot de passe du keystore (2fois) : 123Soleil!
​​keytool -delete -alias ldp.virtual-assembly.org -keystore keystore.jks
​​keytool -importkeystore -v -srckeystore cert_and_key_playX.p12 -destkeystore keystore.jks -srcstoretype PKCS12 -deststoretype JKS -deststorepass 123Soleil! -srcstorepass 123Soleil!
​​
  • ​​Pensez à faire “exit” pour ressortir du sudo su…, sinon, vous resterez en root, et le reste ne fonctionnera pas.
​​
​​Nous avons choisi l'alias "ldp.virtual-assembly.org", même si le certificat est utilisé à la fois pour rww-play et la démo de l'appli VTC. 
​​ 
​​Relancer le serveur : 
​​ 
​​ sudo kill | sudo lsof -t -i:9001 
  • ​​Si cette commande ne fonctionne pas en une fois, taper sudo lsof -t -i:9001, notez le numéro et killez ensuite ce numéro de process
​​ 
​​ cd ~/rwweb-0.7.2-SNAPSHOT/
​​ bin/rwweb -Dhttp.port=9001 -Dhttps.port=8443 -Dhttps.keyStore=/home/av/letsencrypt/AV/keystore.jks -Dhttps.keyStorePassword=123Soleil! -Drww.root.container.path=/home/av/ldpwww -Dhttp.hostname=ldp.virtual-assembly.org &
​​
​
​Nettoyage des autres KeyStore maintenant inutiles
​​ 
​​Maintenant que nous sommes sûr de n'utiliser dans l'avenir qu'un seul KeyStore par nom de domaine (voir un seul keystore tout court) et que keystore.jks semble bien répondre, nous allons nettoyer le reste des fichiers présents. Histoire de faire ça propre et d'éviter des artefacts, nous allons vider chaque keystore avant de les supprimer.
​​ 
​​Première étape, lister les certificats présents:
​​keytool -list -v -keystore my_keystore_name.jks
​​ 
​​Une fois la liste des alias de certificats présents obtenues, éxecuter la commande de suppression pour chacun des alias présents:
​​keytool -delete -alias alias -keystore my_keystore_name.jks
​​ 
​​Puis, supprimons le keyStore lui-même:
​​rm -f ./my_keystore_name.jks
​​ 
​
​Problème constaté
​​ 
​​Sur mobile, l'autorité de certification let's encrypt n'est pas considéré safe. Après recherche, cela semble venir du fait que le p12 soit généré avec le fichier certX.pem plutôt que le fullchainX.pem en entrée. Je vais donc tenter de régler le problème en régénérant le p12, en vidant le keystore et en remettant le certificat. Voilà les commandes:
​​cd ~/lets-encrypt/av
​​rm -f cert_and_key_* // Suppression des p12 pour nettoyage
​​openssl pkcs12 -export -in fullchain2.pem -inkey privkey2.pem -out cert_and_key2.p12 -name ldp.virtual-assembly.org -CAfile fullchainX.pem -caname root
​​keytool -list -v -keystore my_keystore_name.jks // Listing des certifs
​​keytool -delete -alias rwwplay -keystore keystore.jks // Suppression du certif
​​keytool -importkeystore -v -srckeystore cert_and_key2.p12 -destkeystore keystore.jks -srcstoretype PKCS12 -deststoretype JKS -deststorepass 123Soleil! -srcstorepass 123Soleil!
​​> Faire un "exit" pour revenir en utilisateur AV
​​sudo kill sudo lsof -t -i:9001​ 
​​cd ~/rwweb-0.7.2-SNAPSHOT/
​​bin/rwweb -Dhttp.port=9001 -Dhttps.port=8443 -Dhttps.keyStore=/home/av/letsencrypt/AV/keystore.jks -Dhttps.keyStorePassword=123Soleil! -Drww.root.container.path=/home/av/ldpwww -Dhttp.hostname=ldp.virtual-assembly.org &
​​ 
​​And it works !
​​ 
​​ 

​
​ Problème de core dump

​​ Je soupçonne le serveur d’être en vrac au niveau de son disque ou de la mémoire...
​​ En relançant le serveur LDP, j’ai reçu le message : 
​​ 
​​ root@c1-10-1-8-62:/home/av/rwweb-0.7.2-SNAPSHOT# bin/rwweb -Dhttp.port=9001 -Dhttps.port=8443 -Dhttps.keyStore=/home/av/letsencrypt/AV/keystore.jks -Dhttps.keyStorePassword=123Soleil! -Drww.root.container.path=/home/av/ldpwww -Dhttp.hostname=ldp.virtual-assembly.org &
​​[1] 29390
​​root@c1-10-1-8-62:/home/av/rwweb-0.7.2-SNAPSHOT# #
​​A fatal error has been detected by the Java Runtime Environment:
​​#
​​Internal Error (os_linux_zero.cpp:285), pid=29390, tid=1091343456
​​fatal error: caught unhandled signal 11
​​#
​​JRE version: OpenJDK Runtime Environment (7.0_65-b32) (build 1.7.0_65-b32)
​​Java VM: OpenJDK Zero VM (24.65-b04 mixed mode linux-arm )
​​Derivative: IcedTea 2.5.3
​​Distribution: Ubuntu 14.04 LTS, package 7u71-2.5.3-0ubuntu0.14.04.1
​​Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
​​#
​​An error report file with more information is saved as:
​​/home/av/rwweb-0.7.2-SNAPSHOT/hs_err_pid29390.log
​​#
​​If you would like to submit a bug report, please include
​​instructions on how to reproduce the bug and visit:
​​http://icedtea.classpath.org/bugzilla
​​
​​J’ai testé ce qu’il propose “ulimit -c unlimited”, mais ça ne change rien...
​​
​​En fait, le problème était que je lançais le serveur LDP en root, au lieu de me remettre en AV !

​
​La suite

​​Actions supplémentaires envisageables sur ce sujet:
  • ​​Installer et prendre en main Certbot pour renouveler automatiquement les certs (comment ça se passe dans le cas d'un JKS d'ailleurs ?)
  • ​​Sur ce serveur spécifiquement, installer un Nginx en Reverse Proxy pour gérer différents noms de domaines en HTTP et en HTTPS
  • ​​...
​​ 
​​