Réponse courte: en HTTP/1.1 c'est mort (pour le use case précis que tu décris). en HTTP/2.0 ... je sais pas :-(
HTTP/1.1
En HTTP/1.1, cela se passe comme suit:
Le client initie une connection TCP sur le port 443 du serveur.
S'ensuit une négociation de la couche de crypto: le fameux SSL.
Ensuite, une fois le canal de communication chiffré établit, les échanges HTTP commencent réellement.
Et, toujours en HTTP/1.1, c'est lors de ces échanges HTTP que le serveur va avoir connaissance du FQDN ciblé par la requête via le header Host: ... Tu vois, j'imagine, le problème: ton serveur sait qu'il doit faire suivre la requête au pi QUE après avoir établit le canal chiffré, pas possible donc de présenter un autre certificat.
Tu as dès lors deux alternatives:
Tout configurer sur le même nom, genre "home.example.com", "portal.example.com", bref, ce que tu veux et de faire ton routage cloud VS calendar sur une base d'URI:
portal.example.com/nextcloud/ => servi via DocumentRoot & co /
portal.example.com/calendar/ => servi à coup de ProxyPass.
A noter que tu te casses p-ê la tête pour rien: Nextcloud gère très bien les calendriers ... de ce coup, ta seconde appli pourrait s'avérer inutile ...
Utiliser un certificat wildcard (*.example.com) sur le Apache de ton laptop, et ne pas te soucier outre mesure de la connection laptop <=> raspi.
HTTP/2.0
J'ai cru comprendre qu'HTTP/2.0 levait cette limitation ... mais je n'est aucune certitude et une lecture rapide de cette page ne me permet pas d'être fixé.
Cependant ce lien semble dire que ça marche tout seul ...
[^] # Re: Pas de risque de bêtise, RTFM ;-)
Posté par LaBienPensanceMaTuer . En réponse au message Apache Virtualhost et plusieurs machines. Évalué à 4.
Réponse courte: en HTTP/1.1 c'est mort (pour le use case précis que tu décris). en HTTP/2.0 ... je sais pas :-(
HTTP/1.1
En HTTP/1.1, cela se passe comme suit:
Et, toujours en HTTP/1.1, c'est lors de ces échanges HTTP que le serveur va avoir connaissance du FQDN ciblé par la requête via le header Host: ... Tu vois, j'imagine, le problème: ton serveur sait qu'il doit faire suivre la requête au pi QUE après avoir établit le canal chiffré, pas possible donc de présenter un autre certificat.
Tu as dès lors deux alternatives:
Tout configurer sur le même nom, genre "home.example.com", "portal.example.com", bref, ce que tu veux et de faire ton routage cloud VS calendar sur une base d'URI:
A noter que tu te casses p-ê la tête pour rien: Nextcloud gère très bien les calendriers ... de ce coup, ta seconde appli pourrait s'avérer inutile ...
HTTP/2.0
J'ai cru comprendre qu'HTTP/2.0 levait cette limitation ... mais je n'est aucune certitude et une lecture rapide de cette page ne me permet pas d'être fixé.
Cependant ce lien semble dire que ça marche tout seul ...