SSLProtocol można ustawić tylko dla pierwszego VirtualHost w pliku konfiguracyjnym. Wszystkie kolejne wpisy VirtualHost odziedziczą to ustawienie od pierwszego wpisu i po cichu zignorują własne ustawienie z powodu błędu OpenSSL .
Istnieje odpowiedni raport o błędzie dla mod_ssl , ale jak opisano w raporcie o błędzie, problem musi zostać rozwiązany w OpenSSL (certyfikat jest dziedziczony, ale nie protokoły).
Zestawy szyfrów muszą być ustawione niezależnie dla każdego VirtualHost, w przeciwnym razie pojawi się lista domyślna, zawierająca wiele niepewnych szyfrów. Należy również pamiętać, że starsi klienci, którzy nie obsługują wskazania nazwy serwera (SNI), zawsze będą używać domyślnego hosta (o ile nie zostanie zablokowanySSLStrictSNIVHostCheck ), co może zakłócać testowanie.
Krótko mówiąc, powinieneś być w stanie określić niestandardowe zestawy szyfrów i certyfikaty dla każdego wirtualnego hosta, ale dopóki błąd nie zostanie naprawiony, nie oczekuj poprawnego działania z niestandardowymi protokołami dla każdego wirtualnego hosta.
Napotkałem ten problem z Apache 2.4 i modssl z OpenSSL 1.0.1k, i spodziewam się, że Apache 2.2 będzie podlegał tym samym problemom.
Aktualizacja (październik 2016 r.): Błąd OpenSSL został oznaczony jako rozwiązany w dniu 13 października 2016 r. Był to jednak część masowego zamknięcia otwartych problemów i chociaż dostarczono „częściowej poprawki”, problem nigdy nie został w pełni rozwiązany.
Aktualizacja (kwiecień 2018 r.): Ponownie zgłoszony błąd OpenSSL ma teraz dostępną łatkę (od 9 kwietnia 2018 r.). Ta poprawka zmieni zachowanie instancji Apache skonfigurowanych z wieloma wirtualnymi hostami SNI:
Odrzuć połączenia niezgodne z vhost SSLProtocol
Zostało to opracowane i przetestowane w wersji 2.4.27 oraz w wersji produkcyjnej z tą wersją. Łatka została zmodyfikowana do wersji 2.4.33 i lekko przetestowana.
Sprawdza to wersję połączenia z protokołem SSLProtocol skonfigurowanym dla wirtualnego hosta, który jest dopasowany na podstawie SNI. Ponieważ połączenie jest początkowo nawiązywane z SSLProtocol skonfigurowanym dla domyślnego hosta dla portu, domyślny host musi zawierać wszystkie protokoły, które będą obsługiwane przez dowolny host wirtualny.
Ta poprawka dodaje dodatkowy status zwracany przez APR_EMISMATCH do funkcji init_vhost, dzięki czemu wywołanie zwrotne ssl_callback_ServerNameIndication zarejestrowane w OpenSSL może zwrócić fatalny alert SSL_AD_PROTOCOL_VERSION. Ma to na celu wygenerowanie takiej samej odpowiedzi na ClientHello, jak w przypadku określenia protokołu SSL, który nie obejmuje danej wersji. Ponieważ wywołanie zwrotne SNI jest wywoływane podczas przetwarzania ClientHello i przed wygenerowaniem odpowiedzi, wydaje się, że właśnie to robi.
Jeśli nagle zobaczysz komunikaty w następującym formacie:
Rejecting version [version] for servername [hostname]
Następnie powinieneś dwukrotnie sprawdzić SSLProtocolswój domyślny host.
SSLStrictSNIVHostChecksą bardzo mile widziane. Jednak z cytowanej dokumentacji należy również zauważyć, że jeśli jest włączony w jakimkolwiek innym hoście wirtualnym, nieświadomi klienci SNI nie mają dostępu do tego konkretnego hosta wirtualnego .