Avec du recul la configuration apache proposé un peut simple. J'en ai testé une nouvelle de mon coté qui me semble OK y comprise pour les accès smart phone et tablette. Je vais aller mettre à jour la page du wiki.
Sans parlé du problème de DNS, vous ne pouvez pas accéder à Medshake depuis le smartphone car celui-ci ne dispose pas de certificats pour pouvoir s'authentifier auprès d'apache. Il nous faut adapter un peut la configuration du serveur web :
Premièrement il faut modifier la directive SSLVerifyClient
et remplacer require
par optional
(pour permettre aux client ne disposant pas de certificat valide : les smartphone et tablette, d’accéder à l'installation).
Puis modifier dans le bloc <Directory /var/www/medshake/>
la directive Require ssl-verify-client
en Require expr %{SSL_CLIENT_VERIFY} == 'SUCCESS'
.
Il faut maintenant autoriser certaines zones à être accéder depuis des client du réseau local (ici j'utilise le réseau 192.168.1.0/24
si le votre diffère pensez à le modifier) qui ne possède pas de certificat valides (typiquement les zones pour phonecapture et public qui est utilisé pour la signature des documents). Pour cela on ajoutes les diréctives suivantes à la configuration Apache :
(j'utilise la directive <Location>
et non <Directory>
car ma config Apache perso utilise php-fpm et non le mod php d'Apache, j'ai mis un encart sur le sujet sur la page Accès distant du wiki, normalement cela devrais fonctionner tout pareil avec la conf classique.
Code : Tout sélectionner
# Accès aux url commençant par /phonecapture/ et /pubic/ autorisé pour les clients du réseau local sans présenter ce certificat valide
<Location ~ /(phonecapture|public)/>
Require ip 192.168.1.0/24
# client de partout avec un certificat valide
Require expr %{SSL_CLIENT_VERIFY} == 'SUCCESS
</Location>
# Autorise l'accès aux assets (js, css et images) et pages de maintenance autorisé pour les clients du réseau local sans présenter ce certificat valide
<Location ~ /(components/|thirdparty/|scss/|img/|js/|favicon.ico|maintenancePublic.html|maintenance.html)>
# Ces ressources peuvent êtres mise en cache
Header setifempty Cache-Control "must-revalidate"
# Fix un bug présent dans le version de apache utilisé dans Debian 10 (2.4.38)
# qui gènère une entête http Etag mal formé et empéche un retrour 304
# quant la ressource est en cache.
# voire https://bz.apache.org/bugzilla/show_bug.cgi?id=45023#c22
RequestHeader edit "If-None-Match" '^"((.*)-gzip)"$' '"$1", "$2"'
Require ip 192.168.1.0/24
# client de partout avec un certificat valide
Require expr %{SSL_CLIENT_VERIFY} == 'SUCCESS
</Location>
# Bloque les accès aux fichiers composer (juste c'est plus propre)
<Location ~ /composer.(json|lock)>
Require all denied
</Location>
C'est possible que le client Android chouine a cause du certificat auto-signé vous pouvez ajouter le certificat de la CA sur votre smartphone pour régler le pb (en le copiant sur la carte SD par exemple) ou utiliser l'autorité de certification lets'encrypt pour disposer d'un certificat signé (compatible avec l'authentification des clients avec certificat ssl de la CA perso, il faut juste changer les directives (SSLCertificateFile
et SSLCertificateKeyFile
avec les éléments fournis par lets'encrypt).
Comme le dit marsante pour le DNS la plus part des box permettent de surcharger les ip fournis par les résolveur en amont, c'est l'option la plus simple. Et pour l'accès a distance pourquoi ne pas vous prendre un domaine chez un registraire, je vous recommande Gandi. Si vous utiliser Gandi et que voitre FAI change votre ipv4 régulièrement je peut vous fournir un script à lancer avec cron qui met à jours automatiquement votre ipv4 en utilisant l'api Gandi (ce qui permet de ce passer de service de dynDNS).