Newsgroup: it.comp.os.linux.sys
Titolo: HTTPS e multi domini

Ciao,
supponiamo di avere un server con 10 domini, 5 dei quali hanno HTTPS configurato, gli altri 5 no.
 
Se accedo via HTTPS ad uno dei 5 non configurati, Apache carica il vhost di default (se non c'è, carica il primo della lista), visualizzando oltre al warning di common-name non corrispondente, il virtulhost sbagliato.
 
Come si può ovviare a ciò ? Non posso attivare SSL a tutti i domini ed al contempo non posso visualizzare il vhost sbagliato a chi cerca di accedere via HTTPS ad un dominio senza https configurato

 Come si può ovviare a ciò ? Non posso attivare SSL a tutti i domini ed al contempo non posso visualizzare il vhost sbagliato a chi cerca di accedere via HTTPS ad un dominio senza https configurato
 
Il caricamento del vhost sbagliato non è il problema (e si risolve con un vhost _default_), 
il problema è l'erroraccio del common-name non valido, 
dato che il vhost di default, per forza di cose, è associato a X domini differenti.

 dato che il vhost di default, per forza di cose, è associato a X domini differenti.
 
 
Nessuno ha una mezza idea ?


Ma i 5 vhost con HTTPS hanno un IP dedicato? Secondo me puoi risolvere
dedicando un indirizzo IP al traffico sulla 80, in modo tale che se
provano https si prendono una porta in faccia, o meglio un redirect.
 
 
-- 
g4b0, linux user n. 369000
http://brosulo.net
 

 provano https si prendono una porta in faccia, o meglio un redirect.
 
L'IP è lo stesso sia per HTTP che HTTPS
Variarlo sarebbe un bagno di sangue.

 Variarlo sarebbe un bagno di sangue.
 
E non risolverebbe in alcun modo il problema, perchè
se io accedo a "
https://www.sito2.tld
" e sito2.tld non
ha SSL configurato, vengo reindirizzato sul vhost di default
(che è configurato per evitare di mostrare il sito1.tld al
posto di sito2.tld) ma ovviamente il CN del vhost di default
non potrà mai corrispondere a www.sito2.tld quindi tutti i brower
si lamenteranno.
 
In pratica, se voglio evitare di mostrare il primo vhost della lista
per tutti i siti senza https, devo creare un vhost di default con ssl
e questo automaticamente mostrerà l'errore ssl di common-name non valido
perchè ovviamente il certificato su default non è associato al vhost
che sto aprendo.


Ma quindi per i siti in HTTPS usi SNI? Puoi provare a vedere se c'é
qualche config, ma non vedo come potresti risolvere. Tu fai una
richiesta sulla porta 443, e se il CN non matcha ti fornisce il default.
Forse puoi disabilitare il vhost di default, ma non ne sono sicuro.



Registrare un certificato valido per tutti i domini.
 
Senza certificato, ovviamente il certificato - che non c'è - non può funzionare.
 
Leonardo
-- 
 
A terrible beauty is born.
                                     - W. B. Yeats, Easter 1916

 Forse puoi disabilitare il vhost di default, ma non ne sono sicuro.
 
Senza vhost di default viene mostrato il primo sito della lista, che è persino
peggio. Agli ignari utenti che accedono via HTTPS ad un dominio, si ritroverebbero
quello di un altro.

 Senza certificato, ovviamente il certificato - che non c'è - non può funzionare.
 
Ma non deve funzionare infatti. 
Sto proprio cercando di bloccare l'https per determinati domini ma non 
saprei come fare, senza assegnare un IP dedicato a ciascun dominio.

Sto proprio cercando di bloccare l'https per determinati domini
 
Per sapere che dominio vuole il client, bisogna che la connessione sia già stata
aperta: altrimenti, lo header client "Hostname:" da dove passa[1]?
 
Quindi l'alternativa è trovare o scriversi un proxy SNI tipo sniproxy... facendo
in modo di mandare la richiesta in crash. Così, l'errore non compare.
 
Ridirigere la richiesta a 
https://www.unicreditbanca.it
 su 
https://mioserver.it
,
senza che compaiano errori, potrebbe essere qualcosa che gli sviluppatori di SSL
hanno cercato di evitare. Si sa quant'è pedante la gente :-)
 
Leonardo
 
[1] a scanso di equivoci, non ho detto che l'hostname NON sia presente entro una
    richiesta SSL ClientHello... ho detto che la richiesta SSL ClientHello è una
    richiesta SSL.


 hanno cercato di evitare. Si sa quant'è pedante la gente :-)
 
Chi ha mai parlato di redirect?
Ribadisco: *NON* devo far funzionare il sito. Niente redirect, niente cose strane.
*NON* deve essere accessibile.
Mi va benissimo un qualunque tipo di errore hardcodato, un forbidden o cose simili
ma *NON* un errore di certificato non valido, che 9 volte su 10, considerato
il livello medio degli utenti, finirà per essere inteso con un: il tuo fornitore
è un incapace ed ha creato male il certificato.
 
Il comportamento attuale, mi andrebbe bene, ma obbliga a creare un certificato 
di default con tutti i domini presenti sulla macchina.
 
Perchè questa storia di google che battezza insicuri tutti i siti non https
potrebbe crearmi non pochi problemi.
Per mille motivi non posso creare centinaia di certificati per ciascun server solo
perchè 1 sito deve finire sotto HTTPS
 
Visto che così facendo tutti gli altri siti sarebbero automaticamente accessibili
tramite porta 443 (dato che la devo aprire), stai pur certo che prima o poi il
browser tenterà di settare di default l'https in fase di navigazione e questo,
sicuramente, spaccherà l'accesso a tutti i siti.
 
E' una problematica che vorrei evitare.
 

E' una problematica che vorrei evitare.
 
Bisognerebbe avere i siti HTTP su una macchina, e una seconda macchina o IP con solo
i siti HTTPS.
 
E a quel punto, se accedi ad 
https://www.pippo.it
 il sito o esiste su IP 2, e allora
tutto funziona, o non esiste e allora è IP 1 e allora ti colleghi a una macchina che
non ha la porta 443 aperta ==> timeout.
 
Leonardo


 non ha la porta 443 aperta ==> timeout.
 
Obbligando alla migrazione del dominio ad ogni attivazione/disattivazione di HTTPS.
 
Non è così semplice, sopratutto quando c'è un pannello di controllo di mezzo
dove gli utenti possono smanettare, per questo chiedevo un workaround.

Obbligando alla migrazione del dominio ad ogni attivazione/disattivazione di HTTPS.
 
Eh, sì.
 
Semplice, robusto, economico. Choose any two :-)


 Semplice, robusto, economico. Choose any two :-)
 
Semplice proprio no. Spostare fisicamente i domini da un server all'altro, quasi mai è semplice.
Per non parlare della propagazione DNS....
Per non parlare che molte zone DNS non sono gestite da me.
Per non parlare che molti utenti hanno hard-codato l'ip del server da qualche parte nel loro codice (si, in questo caso rientrano nella categoria dei cretini)
Per non parlare che molti utenti hanno software con licenza che fa uso dell'IP del server.

Però poi non corrisponderebbero le chiavi....
 
Non corrisponderebbero neanche i certificati: il problema tuo lo danno i siti che SSL
_NON_ ce l'hanno, mica quelli che ce l'hanno.


 _NON_ ce l'hanno, mica quelli che ce l'hanno.
 
Hai ragione, ho detto una cazzata.

Cosa fa, mi indicizza la pagina di errore certificato ?
 
Non credo. Google, per ora, non ha interesse a peggiorare i risultati del suo motore
senza ottenere il minimo vantaggio per sé. Sarebbe la definizione di stupido secondo
Cipolla.
 
In futuro magari potrà dire che i siti in HTTP non vengono proprio filati di pezza o
vengono mandati nelle ultime pagine dei risultati (non so se ci sia differenza).


 IP (perché l'alternativa è di contentare _QUEL_ cliente, ma scontentarne altri N).
 
 
"1" era un numero "tanto-per". In realtà, su una macchina ben precisa, ho circa 450 domini e devo attivare SSL ad un centinaio.
 
Quindi ne accontento 100, rischio di farne incazzare 350.
 
E con l'ignoranza di certa clientela mi ritrovo nella situazione di:
 
1) sito SSL non migrabile di IP
2) sito senza SSL non gestito da me e cliente ignorante che non ha alcuna intenzione di collaborare. Prima andava, ora non va più.
 

Quindi ne accontento 100, rischio di farne incazzare 350.
 
Ma quelli che accedevano via SSL al sito, e ora hanno un errore, prima ricevevano un timeout.
 
Quindi, puoi abbastanza legittimamente dire che è semplicemente cambiata la risposta data dal
protocollo: prima "Protocollo errato, risposta mancante" e ora è "Protocollo errato, risposta
errata".
 
Alla domanda che sorgerà istintiva al cliente, "Si può tornare com'era prima?", rispondi "Non
è possibile, perché dipende dai browser degli utenti. Sa, l'evoluzione... i browser più nuovi
diventano sempre più sicuri, e sempre più schizzinosi! Ed il suo sito non ha un protocollo di
sicurezza. In futuro, diventerà sempre più necessario... fra uno o due anni è possibile che i
browser non si collegheranno più al suo sito in nessun caso, o avvertiranno gli utenti che la
connessione è a loro rischio e pericolo e li faranno scappare".
 
"E allora?"
 
"Be', le posso attivare letsencrypt. Ma proprio perché è lei, eh."


 errata".
 
 
No, non è così semplice.
Un conto è mandare in timeout il browser, un altro è mostrare un errore di certificato non valido.

(quindi un mio problema)
 
Ora che mi ci hai fatto pensare: è proprio così.
 
Hai venduto al cliente un sito che non si poteva facilmente upgradare a SSL né spostare
con facilità altrove, e - apparentemente - non glielo hai detto ai tempi.
 
Quindi, sì. Sono tutti e soli guai tuoi.
 
Una soluzione indolore, non c'è.
 
Una soluzione che faccia "poco" male, per qualsiasi valore di "poco", non c'è.
 
Le soluzioni - ammesso che ci siano - sono costose e dolorosissime. Molto probabilmente
peggioreranno anche ulteriormente la situazione (io non so come, ma loro sì).
 
Come si dice: "shit happens". Stacce.



 
 
Posto che secondo me devi risolverti la questione degli IP "non 
migrabili" perchè alla lunga ti limita troppo io farei una cosa del genere:
 
per tutti i siti NON SSL crei il virtualhost SSL con letsnecrypt 
(gestito in automatico da certbot) che fa il redirect al sito in plain 
http. Non ho verificato se il browser protesta per un redirect 301 di 
questo tipo ma a naso non credo.
 
E' un lavoraccio mi rendo conto ma altre soluzioni più facile le escludi 
con i vincoli architetturali che hai.
 
My 2 cents
Steve

 questo tipo ma a naso non credo.
 
Che senso ha attivare SSL su tutti i domini, per poi farne redirect 
alla versione non SSL?
Tanto vale lascialo li.
 
Io vorrei proprio evitare l'attivazione di SSL a tutti.


Ha il senso di non offrire un servizio gratis ai tuoi clienti ma 
eventualmente di valorizzarlo commercialmente.
 
Visti i vincoli che hai non vedo soluzioni che li soddisfino tutti.
Buona fortuna :D