Apache2, debian etch i abdurdalnie nie działające SSL
Byłem i zakupiłem certyfikat typu wildcard dla jednej z administrowanych domen. Taki to wymóg pojawił się w obsługiwanej przeze mnie firmie, coby korzystający z aplikacji webowych klienci tejże bezpieczniej się czuli wymieniając dane z serwerem. Nie jest to certyfikat z “zielonym paskiem” (swoją drogą jest to niezły absurd jako wysoko płatne bezpieczeństwo, szczególnie jak ktoś ma oskórkowanego FF/IE/Opera/whatever…) Kupiłem go od firmy polskiej, coby obce imperialistyczne świnie wolnorynkowe elementy ze znaczącym udziałem kapitału zagranicznego nie pasły się kosztem firmy.
Generacja certyfikatu oczywiście za pomocą paczki openssl - prosta komenda openssl req -new -key server.key -out server.csr i już mamy żądanie, które musimy wrzucić do Centrum Certyfikującego. Jak na razie wszystko fajnie i działa - abstrahując od tego, że oważ firma nie za bardzo przygotowana była ze swoim systemem sprzedaży webowej do certyfikatów typu wildcard i chciała wysyłać mi maila na adres webmaster@*.firma.com.pl albo sprawdzać siakieś pliki na takowymż serwerze. Niemniej pomoc ichnia zadziałała szybko i poprawnie i bezproblemowo certyfikat ów dostatałem wraz z instrukcjami jak to go wgrać do mego apache/iis/whatever_web_server. Miłe.
Niestety mój apache, (w przeciwieństwie do IIS, który łyknął wszystko bez słowa), stwierdził w zasadzie, że on nie obsługuje SSL pomimo całej odprawionej w konfiguracji virtual hosta magii mówiącej wprost, że SSL działać ma, że klucze i certyfikaty są (zweryfikowane) w odpowiednich miejscach:
SSLCertificateFile /etc/apache2/ssl/server.crt
SSLCertificateKeyFile /etc/apache2/ssl/server.key
SSLCACertificateFile /etc/apache2/ssl/ca-bundle.crt
Zgłaszał to na dodatek tak uprzejmie, że rzucał kodem nie do odnalezienia, informując poprzez FF/IE, że “blah.firma.com.pl wysłał nieprawidłowy lub niespodziewany komunikat. Kod błędu: -12263″. Wredne to o tyle, że włożenie w google “-12263″ zwróciło mi 0 wyników… Niemniej problem okazał się absurdalny w sensie swojej prostoty. Otóż (błędnie) nie miałem podefiniowanych wirtualnych hostów jako stojących na odpowiednich portach, tj. brakowało mi w odpowiedniej linijce informacji o porcie:
<VirtualHost *:443>
Dokonana w ten sposób separacja pomiędzy hostami szyfrowanymi (443) i nieszyfrowanymi (80) załatwiła sprawę… ale nie do końca. W końcu klient chciał coby komunikacja zachodziła w sposób bezpieczny. Ponieważ obciążenia serwera średniomałe w pliku odpowiadającym za port 80 dorzuciłem co następuje:
RewriteCond %{SERVER_PORT} ^80$
RewriteRule ^(.*)$ https://%{SERVER_NAME}$1 [L,R]
RewriteLog “/var/log/apache2/rewrite.log”
RewriteLogLevel 2
No i śmiga, loguje gdzie trza co trza i jeszcze spełnia założenia firmy. Ufff.
P.S.
Oczywiście wszystko to jest przy założeniu, że wcześniej wykonało się takie magiczne komendy w Debianie, które powrzucały w /etc/apache2/mods-enabled i /etc/apache2/sites-enabled odpowiednie moduły i site’y. Wystarczyło w tym celu wykonać sekwencję:
a2enmod rewrite
a2enmod ssl
i sprawdzić czy wszystko działa za pomocą apache2ctl -t Ale to przecież oczywiste…

