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