Agendav - Cannot connect anymore : "Internal server error"

,

Hello,

When I want to connect to agendav from the yunohost interface, I got an error Internal server error (see below)

It seems to be a certificate issue. Does someone has the same issue ? And has been able to solve it ?
It could be linked to this thread : Baikal since upgrade to yunohost 2.4 and @bidroik

Baikal runs as I am able to add events from my smartphone or thunderbird and see them on the ither device.

History
I used to have a “blank page” when I was using agendav before (see Jappix not working after update to YunoHost 2.4)
I did not used Agendav anymore because of this issue but an updated arrived and I give it a try. Now, it is really broken

Logs

tail /var/log/agendav/2016-09-28.log
[2016-09-28 22:41:26] myapp.CRITICAL: GuzzleHttp\Exception\RequestException: cURL error 60: SSL certificate problem: self signed certificate in certificate chain (see http://curl.haxx.se/libcurl/c/libcurl-errors.html) (uncaught exception) at /var/www/agendav/web/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php line 187 {"exception":"[object] (GuzzleHttp\\Exception\\RequestException(code: 0): cURL error 60: SSL certificate problem: self signed certificate in certificate chain (see http://curl.haxx.se/libcurl/c/libcurl-errors.html) at /var/www/agendav/web/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php:187)"} []

Need more logs ? just ask :slight_smile:

Yunohost is up to date and has been rebooted a couple of time

"host": "Debian 8.6",
    "kernel": "3.14.32-xxxx-grs-ipv6-64",
    "packages": {
        "yunohost": "2.4.2",
        "yunohost-admin": "2.4.2",
        "moulinette": "2.4.0.1",
        "ssowat": "2.6.0"

Thanks for reading until there !

Hello,

I do not know if your problem is the same as mine.

I just tell you what I did when I understood that the problem was about certificate management. The idea is to see what are doing the php-fm processes with strace.

1 - If you have one, close the window (or tab) from where you are connected to agendav
2 - Get the pid list for php-fm agendav processes :

ps -C php5-fpm -o pid,args | awk '$0 ~ /agendav/ {sum=sum","$1} END{print substr(sum,2)}'

The above command line give you a comma separated list of pid, let’s say "10,11,12"
3 - Start to trace these pids with starce with :

 strace -f -p 10,11,12 -e trace=file 2>&1 | grep '/etc/ssl'

4 - now open the agendav application and when you see the error message, look at your terminal to see the strace output

On my side I saw that :

[pid   11] stat("/etc/ssl/certs/af6cfc12.0", {st_mode=S_IFREG|0644, st_size=1168, ...}) = 0
[pid   11] open("/etc/ssl/certs/af6cfc12.0", O_RDONLY) = 9
[pid   11] stat("/etc/ssl/certs/af6cfc12.1", {st_mode=S_IFREG|0644, st_size=1168, ...}) = 0
[pid   11] open("/etc/ssl/certs/af6cfc12.1", O_RDONLY) = 9

ps : note that the above output was taken when the problem was already solved, it may be different for you

5 - And now execute the command “ls -l” on each path you see in the strace output. On my side one of the link’s target was not the yunohost certifcate which is should be something like this (this is just an example) :

# ls -l /etc/ssl/certs/af6cfc12.1
  /etc/ssl/certs/af6cfc12.1 -> ca-yunohost_crt.pem
# ls -l /etc/ssl/certs/ca-yunohost_crt.pem
  /etc/ssl/certs/ca-yunohost_crt.pem -> /etc/yunohost/certs/yunohost.org/ca.pem

Hope this helps

@+

Thanks for the detailed howto. It seems that one certificate is missing from what I understand.

# ps -C php5-fpm -o pid,args | awk '$0 ~ /agendav/ {sum=sum","$1} END{print substr(sum,2)}'
2223,2224,2225,2509
# strace -f -p 2223,2224,2225,2509 -e trace=file 2>&1 | grep '/etc/ssl'
[pid  2225] stat("/etc/ssl/certs/f9d755d8.0", 0x787d78569690) = -1 ENOENT (No such file or directory)
^C
# ls -l /etc/ssl/certs/f9d755d8.0
ls: impossible d'accéder à /etc/ssl/certs/f9d755d8.0: Aucun fichier ou dossier de ce type
# ls -l /etc/ssl/certs/f9d*
ls: impossible d'accéder à /etc/ssl/certs/f9d*: Aucun fichier ou dossier de ce type

I remember that I had to install the package ca-certificates when I installed Yunohost.
I will check later what package should be missing with apt …

Hello,

I do not know exactly how is working the certificate management in Debian.

After reading the “update-ca-certificates” man page I understand that a certificate which is not chip by Debian should be located in /usr/local/share/ca-certificates with a ‘.crt’ extension.
When “update-ca-certificates” is called, after doing its job, it calls “c_rehash”. “c_rehash” calculate a “hash” and create symlink. Symlinks are named with the calculated hash and their target are another symlink named with the name of the certificate.

Last days there were several update concerning ssl libraries, I guess that’s what broke your certificate management (?)

In my yunohost installation, yunohost cert (symlink) are located in ‘/etc/ssl/certs’ :

$ ls -l | grep ca-yuno
lrwxrwxrwx 1 root root     19 Sep 10 21:11 3ed2547e.0 -> ca-yunohost_crt.pem
lrwxrwxrwx 1 root root     19 Sep 10 20:51 af6cfc12.0 -> ca-yunohost_crt.pem
lrwxrwxrwx 1 root root     19 Sep 10 21:11 af6cfc12.1 -> ca-yunohost_crt.pem
lrwxrwxrwx 1 root root     39 Aug  4  2015 ca-yunohost_crt.pem -> /etc/yunohost/certs/yunohost.org/ca.pem

As you can see I have three “hashed” symlink which are pointing on the same “ca-certificate”.

For the fun I remove 3ed2547e.0, af6cfc12.0 and af6cfc12.1. Agendav send me the same message as yours.

I ran the command ‘c_rehash’, and symlinks have been regenerated :

$ c_rehash 
Doing /usr/lib/ssl/certs
[...]
ssl-cert-snakeoil.pem => af6cfc12.0
[...]
ca-yunohost_crt.pem => af6cfc12.1
ca-yunohost_crt.pem => 3ed2547e.0
[...]
$ ls -l | grep ca-yuno
lrwxrwxrwx 1 root root     19 Oct  1 10:25 3ed2547e.0 -> ca-yunohost_crt.pem
lrwxrwxrwx 1 root root     19 Oct  1 10:25 af6cfc12.1 -> ca-yunohost_crt.pem
lrwxrwxrwx 1 root root     39 Aug  4  2015 ca-yunohost_crt.pem -> /etc/yunohost/certs/yunohost.org/ca.pem

You can see that “af6cfc12.0” is missing and agendav is not working anymore.

“af6cfc12.0” is missing because it is used by another cert (see c_rehash output) :

$ ls -l af6cfc12.0
lrwxrwxrwx 1 root root 21 Oct  1 10:24 af6cfc12.0 -> ssl-cert-snakeoil.pem

I removed this symlink and recreate it :

$ rm af6cfc12.0
$ ln -s ca-yunohost_crt.pem af6cfc12.0

Agendav is now working.

So, two questions :

  • Agendav seems to have the needs of a symlink with a specific name (probably it is related to debian cert management)
  • Why and/or how “c_rehash” generate symlink names

For your case I guess you shoud do :

  • Be sure that you have a symlink “/etc/ssl/certs/ca-yunohost_crt.pem”
  • Be sure that the symlink’s target is the yunohost ca file and that you can access to (just do a “ls” on the path)
  • Create the symlink by :
$ cd /etc/ssl/certs
$ ln -s ca-yunohost_crt.pem f9d755d8.0

If you like danger :-), before creating the symlink you can run the command “c_rehash” and verify if the symlink “f9d755d8.0” exists and if its target is the yunohost ca or another (in that case you will have to remove it).

I’am thinking it is not a really good way to do that kind of stuff, but without a better knowledge about cert management …

Hope this helps too

Hello,

Thanks to your researches, I have found the issue and Agendav works now. I hope my fix is the right way to do it.

Issue
1 - A symlink was missing in /etc/ssl/certs (fixed with c_rehash command)
2 - with “strace”, I found that there was a permission issue. “php-fpm” is owned by “agendav” and cannot access to certificate owned by root. All other yunohost php-fpm process are owned by root (on my install at least) so there is no issue with them)

# ls -l /etc/ssl/certs/ | grep ca-yuno
lrwxrwxrwx 1 root root     39 févr.  8  2016 ca-yunohost_crt.pem -> /etc/yunohost/certs/yunohost.org/ca.pem

# c_rehash 
Doing /usr/lib/ssl/certs
[...]
ssl-cert-snakeoil.pem => 9138e6dd.0
ssl-cert-snakeoil.pem => dec243de.0
yunohost_crt.pem => f9d755d8.0        <== Was missing 
yunohost_crt.pem => 97678237.0
[...]
# 

# ls -l /etc/ssl/certs/ | grep ca-yuno
lrwxrwxrwx 1 root root     19 oct.   1 13:18 97678237.1 -> ca-yunohost_crt.pem
lrwxrwxrwx 1 root root     39 févr.  8  2016 ca-yunohost_crt.pem -> /etc/yunohost/certs/yunohost.org/ca.pem
lrwxrwxrwx 1 root root     19 oct.   1 13:18 f9d755d8.1 -> ca-yunohost_crt.pem
# 

Some certificates have been created. Lets check agendav php process with strace now

# ps -C php5-fpm -o pid,args | awk '$0 ~ /agendav/ {sum=sum","$1} END{print substr(sum,2)}'
1228,1229,1317,1361,1362

# strace -f -p 1228,1229,1317,1361,1362 -e trace=file 2>&1 | grep '/etc/ssl'
[pid  1361] stat("/etc/ssl/certs/f9d755d8.0", {st_mode=S_IFREG|0640, st_size=5704, ...}) = 0
[pid  1361] open("/etc/ssl/certs/f9d755d8.0", O_RDONLY) = -1 EACCES (Permission denied)
^C

Here we are. Permission issue. Let’s dig

# cd /etc/ssl/certs
:/etc/ssl/certs# ls -l f9d755d8.0
lrwxrwxrwx 1 root root 16 oct.   1 13:18 f9d755d8.0 -> yunohost_crt.pem

:/etc/ssl/certs# ls -l yunohost_crt.pem 
lrwxrwxrwx 1 root root 43 févr.  8  2016 yunohost_crt.pem -> /etc/yunohost/certs/XXX.nohost.me/crt.pem

:/etc/ssl/certs# ls -l /etc/yunohost/certs/XXX.nohost.me/crt.pem 
-rw-r----- 1 root metronome 5704 févr.  8  2016 /etc/yunohost/certs/XXX.nohost.me/crt.pem

Cert is owned by root and by the metronome group.

Agendav runs as agendav user. So php cannot reach the cert :

:/etc/ssl/certs# ps aux | grep agenda
[...]
agendav   1229  0.0  0.9 386148 19176 ?        S    sept.30   0:00 php-fpm: pool agendav                                                   
[...]

On my server, all other php-fpm process run as www-data :

# ps aux | grep php-fpm
root      1223  0.0  0.9 385576 20088 ?        Ss   sept.30   0:06 php-fpm: master process (/etc/php5/fpm/php-fpm.conf)                    
agendav   1228  0.0  0.7 385824 14960 ?        S    sept.30   0:00 php-fpm: pool agendav                                                   
[...]                                   
www-data  1230  0.0  0.8 387248 17948 ?        S    sept.30   0:00 php-fpm: pool baikal                                                    
[...]
www-data  1236  0.0  0.3 385412  6680 ?        S    sept.30   0:00 php-fpm: pool roundcube                                                 
[...]

Certificates permissions :

# ls -l /etc/yunohost/certs/
total 8
drwxr-xr-x 2 root root 4096 févr.  8  2016 XXX.nohost.me
drwxr-xr-x 2 root root 4096 févr.  8  2016 yunohost.org

# ls /etc/yunohost/certs/XXX.nohost.me/ -al
total 32
drwxr-xr-x 2 root root      4096 févr.  8  2016 .
drwxr-xr-x 4 root root      4096 févr.  8  2016 ..
lrwxrwxrwx 1 root root        34 févr.  8  2016 ca.pem -> /etc/ssl/certs/ca-yunohost_crt.pem
-rw-r----- 1 root metronome 5704 févr.  8  2016 crt.pem
-rw-r----- 1 root metronome 1704 févr.  8  2016 key.pem
-rw------- 1 root root      8890 févr.  8  2016 openssl.cnf

Users & group access rights :

# id metronome
uid=117(metronome) gid=124(metronome) groupes=116(ssl-cert),124(metronome)

# grep 'metronome' /etc/group
ssl-cert:x:116:metronome
metronome:x:124:

# grep 'ssl-cert' /etc/group
ssl-cert:x:116:metronome

Only “metronome” is a member of “ssl-cert” group. I could add agendav to this group but it would give access to the cert key too. Which is not wanted…

# id agendav
uid=999(agendav) gid=999(agendav) groupes=999(agendav)

Proposal Fix
1 - All users could access to the cert => chmod r+x /etc/yunohost/certs/XXX.nohost.me/crt.pem (Agendav works with this !)
2 - Agendav php-fpm processes should be owner by root => modify php-fpm config for agendav
3 - If each application has it own php-fpm user. Domain SSL certificate should be copied in each app directory . This issue will happened if other processes want to use a php process owned by a user who is not root
4 - Yunohost acts as a reversy proxy and handles the https connection from the client. But it should not use ssl internaly. I do not see the link with the certification missing. And why agendav needs it :confused:

With fix 1, agendav works. it didn’t test the others yet …
It will try to get a clean install to check the behavior of certificates and agendav !

Root cause
I have no idea what happened. I didn’t customize Yunohost by CLI. Are we the only ones in thi case ??

Bonjour,

Pourrait-on aussi avoir la procédure en français ?

Agendav ne fonctionne pas, et j’ai le même message d’erreur que dans le premier message du topic.

Sur les clients lourds (Evolution Linux) et le caledrier AgenDAV sur android la synchro fonctionne correctement.

Cependant j’aimerai que ca fonctionne aussi via l’application web Agendav.

Par avance merci.

Salut,

Il n’y a pas de procédure standard pour ce problème.

Avant de décider quoi faire, on va contrôler qu’il s’agit bien d’un problème de certificat.

Reprend les étapes qui consiste à tracer les processus php-fm de agendav :

  • ferme l’interface web d’agendav
  • Ouvre un terminal et repère les pid des processus php-fm d’agendav avec cette commande (elle te renvoie une liste séparée par des virgules) :
  ps -C php5-fpm -o pid,args | awk '$0 ~ /agendav/ {sum=sum","$1} END{print substr(sum,2)}'
  • Avec cette liste, lance la commande strace suivante
strace -f -p la_liste_de_pid -e trace=file 2>&1 | grep '/etc/ssl'
  • Maintenant, ouvre l’interface web d’agendav. Tu devrais avoir des messages dans le terminal où tu as exécuté strace. Ces message devraient faire référence à la lecture de fichier dans /etc/ssl/certs.

  • Pour chaque références de fichier, dans la sortie de strace, exécute la commande “ls -l”.

  • Copie nous la sortie de strace ainsi que le résultat des “ls -l”

Avec ça on verra déjà s’il s’agit bien du même problème que ce post.

A+

Bonjour,

Merci infiniment pour ton retour, voici la liste des résultats:

La commande:

ps -C php5-fpm -o pid,args | awk '$0 ~ /agendav/ {sum=sum","$1} END{print substr(sum,2)}'

Je récupère les PID suivants:

3520,3521,3522,3576

Ensuite j’exécute la commande:

utilisateur@nommachine:/etc/ssl/certs# strace -f -p 3520,3521,3522,3576 -e trace=file 2>&1 | grep '/etc/ssl’
utilisateur@nommachine:/etc/ssl/certs#

Il n’y a pas de liste quand j’exécute l’interface web Agendav :disappointed_relieved:.

Bonjour,

J’avais du installer la commande strace car elle n’est pas présente dans Yunohost par défaut (c’est un outils d’informaticien)

Pour vérifier si l’outil est installé, tape la commande : strace -V
Si la commande est installée, tu auras un résultat qui ressemble à : strace -- version 4.9
Sinon, il faudra que tu l’installes avec la commande : apt install strace

Ensuite, tu pourras suivre à nouveau la procédure :slight_smile:

arf … c’est certainement autre chose alors.

Quand tu exécute le strace, il te rend la main tout de suite ? (c’est l’impression que donne ta sortie)

Pour en savoir un peu plus sur l’erreur agendav tu peux passer en environnement de développement en éditant un fichier de configuration.

Ouvre le fichier (avec vim par exemple) /var/www/agendav/web/public/index.php.
À la ligne 8 tu dois avoir ceci :

$environment = 'prod'; // Safe default

Remplace “prod” par “dev” :

$environment = 'dev'; // Safe default

Enregistre ta modification et ouvre agendav, tu devrais avoir un message pas forcement plus clair mais qui nous en dira plus sur ce qu’il se produit à l’ouverture d’agendav.

A+

Oui il me rend la main tout de suite.

J’ai modifié le fichier comme tu me l’as demandé et voici la nouvelle erreur:

> Whoops, looks like something went wrong.

> 1/1
> RequestException in CurlFactory.php line 187:
> cURL error 60: SSL certificate problem: self signed certificate in certificate chain (see http://curl.haxx.se/libcurl/c/libcurl-errors.html)

Après y’a des info un peu trop sensible…

@bidroik et @Gofannon
Vu que je reçois des mails lorsque quelqu’un répond, tu as du voir les informations dites sensibles … J’espère que personne n’aura l’intention de commettre un acte de malveillance … :disappointed_relieved:

@Gofannon
Effectivement, le paquet n’etait pas installé …

Voila ce que Strace m’indique:
> [pid 3522] stat("/etc/ssl/certs/35154771.0", 0x7ffd3a041160) = -1 ENOENT (No such file or directory)

A première vu le fichier qu’il cherche n’existe pas. Que faire ?

Je m’en doutais, c’est curieux que tu n’aies pas eu un message du style la commande n’existe pas … m’enfin c’est réglé

Y’a des chances que ce soi ça

Pas de soucis c’est suffisant pour confirmer l’hypothese. Le certificat ne peut pas être vérifié par le certificat de la CA.

Je ne comprends pas … À mon avis tu n’as pas à t’inquiéter je n’ai rien vu qui pourrait être des informations sensibles

  • En root, vas dans /etc/ssl/certs
# cd /etc/ssl/certs/
  • Vérifie que le fichier “ca-yunohost_crt.pem” existe et qu’il pointe (c’est un lien) sur “/etc/yunohost/certs/yunohost.org/ca.pem”
# ls -l ca-yunohost_crt.pem
[...] ca-yunohost_crt.pem -> /etc/yunohost/certs/yunohost.org/ca.pem
  • Si oui recréer le lien avec :
# ln -s ca-yunohost_crt.pem 35154771.0

Réessaie d’ouvrir agendav et ça devrait fonctionner

1 Like

Formidable, avec la manipulation, ça fonctionne maintenant c’est super !!

Merci infiniment !

Bonjour,

je rencontrais le même problème (nouvelle installation de yunohost).
La commande : ls -l /etc/ssl/certs/ | grep ca-yuno, ne m’a retourné qu’un seul certificat.
J’ai ensuite effectué sudo c_rehash pour générer les certifs et agendav a fonctionné.

merci pour les infos !

1 Like

magnifique !
wonderful!

Beaucoup plus propre que les liens symboliques.
Much cleaner than the symbolic links.

$ sudo c_rehash

ça fait le taf
makes the job!

Bonjour,

Ça a recommencé !

Même symptômes même erreurs. J’ai donc creusé un peu plus.

Il se trouve que le certificat yunohost et le certificat “snakeoil” (utilisé dans le cas ou une com chiffrée est nécessaire, certificat par défaut donc) on le même hash :

$ for i in ca-yunohost_crt.pem ssl-cert-snakeoil.pem ; do openssl x509 -hash -noout -in $i ; done
af6cfc12
af6cfc12

Lors des dernières mise à jour de debian il y a eu des mise à jour du paquet “ca-certificates”. Je suppose que c’est cette mise à jour qui “casse” les liens symboliques de “/etc/ssl/certs”.
Je suppose que le processus d’installation de yunohost s’appuie d’une façon ou d’une autre sur le processus de création du certificat “snakeoil” de debian pour créer les certificat propres à mon install de yunohost (je n’ai pas creusé ce point).

Bref, l’idée est donc de générer un nouveau certificat “snakeoil” afin qu’il n’y ait plus de collision entre les deux certificats.

  • Générer un nouveau certificat “snakeoil”
$ make-ssl-cert generate-default-snakeoil --force-overwrite
  • Son hash
$ openssl x509 -hash -noout -in ssl-cert-snakeoil.pem
d17093c5
  • Suppression du lien symbolique qui pointe sur le certificat snakeoil (cette étape n’est probablement pas nécessaire car il semble que “c_rehash” commence par supprimer tous les liens symboliques … mais bon comme je l’ai fait je le note ici)
$ rm af6cfc12.0
  • Génération des lien symbolique dans “/etc/ssl/certs”
$ c_rehash
  • Maintenant on est bon
$ for i in ca-yunohost_crt.pem ssl-cert-snakeoil.pem ; do openssl x509 -hash -noout -in $i ; done
af6cfc12
d17093c5

C’est probablement un peu bourrin et je n’ai pas envie d’aller plus loin.

J’espère que je serai tranquille maintenant :slight_smile: … On verra à la prochaine mise à jour debian

En espérant que cela vous sera utile.

A+