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