bramki antyspamowe i LDAPS

Niedawno miałem ciekawy przypadek przy konfiguracji bramki Symantec Messaging Gateway. Dla lepszej ochrony systemu pocztowego (jak dla mnie oczywiście Exchange), bramki te, podobnie jak wiele innych tego typu rozwiązań, pobierają z katalogu LDAP listę adresową organizacji. W ten sposób mogą weryfikować listę odbiorców dla poczty przychodzącej i listę nadawców dla poczty wychodzącej. W ten sposób również użytkownicy Exchange mogą łączyć się do swojej kwarantanny, znajdującej się na bramce. Konfiguracja integracji bramki antyspamowej z Active Directory jest stosunkowo prosta i polega na wskazaniu serwera, DN konta używanego do czytania danych (w przypadku AD może być również UPN tego konta), no i oczywiście hasła tego konta. Dodatkowym atrybutem połączenia jest port TCP (domyślnie 389). Kolejnym krokiem jest test połączenia.

Przy próbie połączenia kreator pokazywał mi błąd, świadczący o nieprawidłowym koncie. Jednak próba połączenia z AD z komputera domenowego działała poprawnie. Po weryfikacji haseł, ustawień firewalla i innych kwestii sieciowych, sprawdziłem polisy GPO. Okazało się, że zarówno na kontrolerach domenowych, jak i na stacjach roboczych jest ustawione wymuszenie podpisywania pakietów LDAP (LDAP signing). Niestety funkcja ta powoduje problemy z uwierzytelnieniem z urządzeń takich jak SMG czy SonicWall.

Alternatywą było ustawienie połączenia na LDAPS. Przełączyłem port na 636 (domyślny port połączenia LDAPS) i tym razem dostałem komunikat, że nie mogę nawiązać połączenia z serwerem. O co chodzi? Człowiek przyzwyczaił się, że w środowisku domenowym wdrażany jest do wewnętrznych celów organizacji urząd certyfikacyjny (CA), a że całkiem sporo firm instaluje CA na kontrolerze domeny, a w takim wypadku dla kontrolerów domyślnie instalowane są certyfikaty, właśnie służące do szyfrowania komunikacji LDAP (czyli właśnie LDAPS). Jeżeli jednak w AD nie ma zainstalowanego urzędu certyfikacji, to takich certyfikatów niestety nie ma domyślnie zainstalowanych, więc LDAPS nie działa. Jak to zmienić? Bardzo prosto. Można oczywiście wdrożyć urząd certyfikacyjny na jednym z serwerów Windows, jednak nie zawsze jest to możliwe. Tak naprawdę, do uruchomienia LDAPS na kontrolerach domeny możemy użyć dowolnego urzędu CA, do którego mamy dostęp, żeby wygenerować potrzebne nam certyfikaty. Dobra instrukcja, jak to zrobić znajduje się na stronach wikipedii Technet. Możemy jednak postąpić jeszcze prościej - użyć certyfikatów self-signed. Tak naprawdę do uruchomienia LDAPS certyfikaty muszą spełniać 3 warunki:

1. Certyfikat musi obsługiwać funkcję Server Authentication. Czyli innymi słowy musi zawierać Server Authentication OID: 1.3.6.1.5.5.7.3.1
2. Atrybut Subject Name lub pierwsza nazwa w atrybucie Subject Alternative Name (SAN) musi  być zgodna z nazwą Fully Qualified Domain Name (FQDN) serwera - np. SubjectCN=server1.contoso.com
3. W lokalnym magazynie konta komputera musi znajdować się klucz prywatny certyfikatu.

Czyli możemy z linii komend wygenerować certyfikat komendą:
certreq -New -Machine policy.inf

Wcześniej oczywiście musimy sobie przygotować plik policy.inf zawierający niezbędne informacje.

Kilka przykładów prostego i bardziej rozbudowanego pliku znalazłem na blogu Oskara Virota.

Jeżeli jednak kontrolery domeny są w wersji Windows 2012 lub nowszej możemy użyć cmdleta powershell New-SelfSignedCertificate, 

Tworząc certyfikat nawet przy minimalnej ilości atrybutów uzyskamy odpowiedni wynik, chociaż certyfikat będzie miał standardową długość życia certyfikatu (jeden rok):

New-SelfSignedCertificate -DnsName "server1.contoso.com" -CertStoreLocation "cert:\LocalMachine\My"

Teraz musimy wyeksportować certyfikat (najlepiej w formacie Base64) i zaimportować go ponownie, tym razem wybierając magazyn Zaufanych Głównych Urzędów Certyfikacji, na wszystkich kontrolerach domeny, z którymi chcemy, żeby komunikacja LDAPS działała (oczywiście na nich również powinniśmy wygenerować i wyeksportować kolejne certyfikaty), oraz na bramce SMG.
Po restarcie kontrolera domeny połączenie LDAPS powinno uruchomić się bez problemów.

SHA-1 do wymiany

Początek roku przyniesie nam spore zamieszanie w obszarze certyfikatów webowych. Wiele firm korzysta wewnętrznie z urzędów certyfikacji, które zostały zainstalowane kilka, a nawet kilkanaście lat temu, z domyślnym podpisem SHA-1, który od kilku lat jest uznawany za niewystarczający. Producenci przeglądarek od jakiegoś czasu zaczęli ostrzegać użytkowników o tym, że takie certyfikaty są potencjalnie niepoprawne (np. Chrom już od wersji 39 wyświetla ostrzeżenia o błędach certyfikatu). Aktualna wersja (Chrome 50) wyświetla informację, że o błędnym certyfikacie.

Jednak sytuacja diametralnie zmieni się w najbliższych tygodniach. Google ogłosił, że nowa wersja Chrome 56, planowana na koniec stycznia 2017 nie będzie otwierać stron zabezpieczonych certyfikatem z SHA-1.
Podobnie Firefox ogłosił politykę wygaszania wsparcia dla SHA-1, Nowa wersja Firefox 51, planowana do dystrybucji, podobnie jak Chrome 56 w styczniu 2017 ma również blokować dostęp do stron zabezpieczonych certyfikatem wystawionym przez urząd główny z SHA-1.

Co prawda można użyć polis konfiguracyjnych, które pozwolą na dalsze użycie takich certyfikatów, ale nie będzie to dla standardowych użytkowników takie proste.

Do tego trendu dołączył Microsoft, ogłaszając, że w dniu 14 lutego 2017 zostanie wydana poprawka dla przeglądarek Internet Explorer i Edge, która zacznie wyświetlać okno z informacją, że certyfikat jest niezaufany, a w kolejnym kroku blokada będzie całkowita.

Dokładniejsza informacja na ten temat opublikowana została na stronach Technetu.

Jak się ustrzec przed takimi problemami? Nie pozostaje nic innego niż zmienić certyfikat swojego urzędu certyfikacji, wykorzystując SHA-256 (pamiętajmy o tym że TLS 1.0-1.2 nie wspierają mocniejszych podpisów jak np. SHA-512, więc ustawienie bardzo mocnego algorytmu też nie jest zalecane). Instrukcja jak to zrobić, dostępna jest na stronach Microsoftu, a także na wielu innych blogach.

Problem z certyfikatami Starfield w Firefoxie

Właśnie zauważyłem, że nowa wersja Firefoxa blokuje certyfikaty Starfield, nawet jeżeli doda się wyjątek bezpieczeństwa:

Dopiero zaimportowanie certyfikatu urzędu pośredniczącego rozwiązuje ten problem. W tym celu wchodzimy w Firefoxie w Opcje -> Zaawansowane -> Certyfikaty -> Wyświetl certyfikaty -> Organy certyfikacji –> Importuj.

Następnie wskazujemy certyfikat “Stafield Secure Certification Authority” i potwierdzamy import, zanaczając dodatkowo opcję “Zaufaj temu certyfikatowi przy identyfikacji witryn internetowych”.

Kolejne połączenie przebiegnie pomyślnie. Co ciekawe problem pojawił się ostatnio i występuje tylko w Firefoxie. Ciekaw jestem czy podobne problemy pojawiły się dla jakiś innych dostawców certyfikatów?

Nietypowy certyfikat dla puli Lyncowej

Niedawno miałem ciekawy problem (LS Protocol Stack event 14501 i 14428), dotyczący koegzystencji serwerów Lync z infrastrukturą Cisco CUCM/VCS. Pomimo faktu wygenerowania certyfikatów przez ten sam wewnętrzny urząd połączenia TLS pomiędzy serwerami zgłaszały błędy. Znalazłem w sieci podobny przypadek, jednak przygotowanie certyfikatu dla takiego scenariusza (domyślnie certyfikat serwera Lync jest konfigurowany tylko dla certyfikacji serwerowej (OID 1.3.6.1.5.5.7.3.1), a w tym wypadku jest wymagana dodatkowo certyfikacja kliencka (OID 1.3.6.1.5.5.7.3.2). Jak to zrobić najprościej? Domyślne metody nie pozwalają na taką operację – ani kreator certyfikatów z Lync Deployment Wizarda ani tym bardziej zawarty w IIS, formatka webowa urzędu certyfikacyjnego również nie pozwala na utworzenie takiego certyfikatu. Jednak narzędzia linii komend certreq/certutil mają bogate możlwości, które nam to ułatwią. W tym celu musimy sobie przygotować plik inf, zgodnie z artykułem “How to request a certificate with a Custom SAN”. Pik powinien zawierać wpisy jak poniżej:

[Version]
Signature="$Windows NT$"

[NewRequest]
Subject = "CN=lync.pepug.org"  
Exportable = TRUE                   ; Private key is exportable
KeyLength = 2048                    ; Common key sizes: 512, 1024, 2048, 4096, 8192, 16384
KeySpec = 1                         ; AT_KEYEXCHANGE
KeyUsage = 0xA0                     ; Digital Signature, Key Encipherment
MachineKeySet = True                ; The key belongs to the local computer account
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = CMC

[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 ;Server Authentication
OID=1.3.6.1.5.5.7.3.2 ;Client Authentication

[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns=lync.pepug.org&"
_continue_ = "dns=fe1.lab.pepug.org&"
_continue_ = "dns=fe2.lab.pepug.org&"
_continue_ = "dns=lsweb.pepug.org&"
_continue_ = "dns=lyncdiscover.pepug.org&"
_continue_ = "dns=lyncdiscoverinternal.pepug.org&"
_continue_ = "dns=dialin.pepug.org&"
_continue_ = "dns=meet.pepug.org&"
_continue_ = "dns=sip.pepug.org"

[RequestAttributes]
CertificateTemplate = WebServer1

Dwa słowa komentarza – w sekcji EnhancedKeyUsageExtension wskazujemy, że ma być obsługiwana zarówno opcja Server jak i client Authentication. Ponieważ chcemy certyfikat zainstalować na kilku serwerach w puli, więc wybieramy opcję zezwolenia na eksport klucza prywatnego. W sekcji RequestAttributes wskazujemy wykorzystywany w naszej firmie szablon tworzenia certyfikatu, jednak najciekawszy zapis zawiera sekcja Extensions – ponieważ certyfikat serwera Lync musi zawierać zarówno nazwy hostów jak i szereg innych nazw wykorzystywanych przez Lynca, więc wykorzystujemy specyficzny zapis z użyciem konkretnego identyfikatora dla certyfikatów SAN (zapis działa począwszy od Windows 2008).

Wygląda to trochę nietypowo, ale działa. Teraz tylko pozostaje utworzenie certyfikatu z użyciem narzędzia certreq:

Na jednym z serwerów wykonujemy komendę:

certreq –new certLync.inf certLync.req

Następnie po skopiowaniu pliku (ewentualnie zdalnie, jeżeli jest taka możliwość) na serwer z urzędem certyfikacji generujemy certyfikat:

certreq –submit certLync.req certLync.cer

Teraz pozostaje tylko zainstalowanie certyfikatu:

certreq -accept certLync.cer

i przypisanie go do usług serwera FrontEndowego (no i po wyeksportowaniu do pfx-a instalacja na drugim serwerze w puli).

Po restarcie usług komunikacja pomiędzy systemami zaczyna działać poprawnie.

Zmiany w certyfikatach publicznych

Kiedy Microsoft ogłosił w drugiej połowie zeszłego roku koniec wsparcia dla certyfikatów wykorzystujących SHA-1 z dniem 1.01.2017, wydawało się to terminem odległym. Jednak Google już od listopada 2014 zaktualizował przeglądarkę Chrome, tak żeby wyświetlała ostrzeżenia dla certyfikatów z SHA-1, wygasających w 2017 roku i stopniowo takie obostrzenia będą się powiększać. Co zatem należy zrobić? Przejść na certyfikaty wykorzystujące SHA-2 (przeważnie jest to SHA-256). Na pozór nic prostszego. Jednak odnowienie certyfikatów do Exchange u kilku klientów w ostatnich dniach pokazało mi, że dostawcy już taką zmianę realizują – nowe certyfikaty, m. in GoDaddy czy też RapidSSL przychodzą ze zmodyfikowaną wersją algorytmów. Co ciekawe, w przypadku zaleceń dla serwerów Exchange zarówno kreator jak i cmdlet generujący nowy wniosek o certyfikat używają domyślnie (i nie ma możliwości tego zmienić) SHA-1. Mam nadzieję, że zespół Exchange wkrótce się obudzi i zostanie to poprawione w kolejnych wersjach (w tym kwartale powinien być dostępny kolejny Cummulative Update). Jak na razie rozwiązanie jest proste, chociaż nie tak oczywiste.

Mając stary certyfikat podpisany SHA-1, dostajemy po wniesieniu opłaty nowy certyfikat wygenerowany przez dostawcę, zgodnie z danymi firmy. Jednak jego standardowy import na serwer z poziomu narzędzi Exchange lub konsoli IIS nie podłącza go do klucza prywatnego.

Stosujemy zatem obejście opisane w artykule bazie wiedzy Microsoft KB889651 lub na serwisach dostawców certyfikatów.

Czyli po sprawdzeniu numeru seryjnego certyfikatu wykonujemy komendę:

certutil –repairstore my <serial number>

Certyfikat został podpięty do klucza prywatnego, teraz możemy podłączyć usługi Exchange, Lynca czy dowolne inne.

Publiczne certyfikaty dla Lync Servera

Dawno nie zaglądałem do artykułu http://support.microsoft.com/kb/929395/en-us, który wymienia urzędy certyfikacyjne, które są zalecane dla usług Unified Communications. Przez bardzo długi czas były na liście dostępne tylko 3 certyfikaty (z chwilowym pobytem urzędu GoDaddy), ale jak widać w aktualizacji dokumentu z września 2013, urzędów jest teraz aż osiem. Warto o tym pamiętać, zwłaszcza pod kątem problemów z konfiguracją wymaganego do publikacji prezentacji powerpointowych certyfikatu dla serwera Office Web App Server (nie działa poprawnie z certyfikatem wiildcardowym), więc optymalne jest użycie na serwerze WAS certyfikatu z urzędu wewnętrznego, schowanie serwera WAS za Reverse Proxy (np. sprzętowym Load Balancerem) i tam opublikowanie certyfikatu zawierającego wszystkie nazwy, zalecane przez Microsoft w dokumentacji - Request and Configure a Certificate for Your Reverse HTTP Proxy.

Zalecane przez Microsoft dla serwerów Lync urzędy certyfikacyjne :

• Entrust http://www.entrust.net/microsoft/ 
• Comodo http://www.comodo.com/msexchange 
• DigiCert http://www.digicert.com/unified-communications-ssl-tls.htm 
• GlobalSign http://www.globalsign.com/ssl/buy-ssl-certificates/unified-communications-ssl/ 
• WISeKey http://www.wisekey.com/en/Products/digital-identities/Pages/ssl-solutions.aspx 
• GeoTrust http://www.geotrust.com/ssl/ssl-certificates-san-uc/ 
• Thawte http://www.thawte.com/ssl/san-uc-ssl-certificates/index.html 
• Symantec (czyli VeriSign)
  https://www.symantec.com/theme.jsp?themeid=san-ssl-certificates

Active Directory Certificate Services Migration Guide

Czy migracja usług certyfikacyjnych na platformę Windows 2008 R2 jest trudna? Można się o tym przekonać z opublikowanego właśnie na Technecie dokumentu Active Directory Certificate Services Migration Guide.

Problemy z usługami webowymi wystawiania certyfikatów dla Windows Mobile

Jednym z problemów związanych z nowymi produktami Microsoftu jest wprowadzanie nowych cech nie do końca zgodnych z poprzednimi wersjami systemu. I tak np. usługi web enrollmentu czyli wystawiania certyfikatów przez www inaczej zachowują się na Windows 2003 i Windows 2008 (co jest zrozumiałe ze względu na inną wersję serwera IIS), ale inaczej też działa wystawianie dla Windows XP i Winows Vista, nawet jeżeli używamy tej samej wersji przeglądarki webowej.

Jeżeli chcemy, żeby web enrollment działał poprawnie dla Visty na platformie Windows 2003 musimy doinstalować specjany dodatek:

How to use Certificate Services Web enrollment pages together with Windows Vista or Windows Server 2008

Wiąże się to z innym modelem bezpieczeństwa i używaniem kontrolek ActiveX na obu tych platformach. Wprowadzenie zmian dla Web Enrollment uniemożliwia jednak obsługę systemu Windows Mobile poprzez strony web enrollmentu. Konieczne są kolejne zmiany w stronach asp. Na szczęście jest to opisane przez Microsoft w kolejnych dokumentach:

Certificate Web Enrollment Pages do not support Windows Mobile devices when they are released on computers that are running Windows Server 2008 or Windows Server 2003 and that have Certificate Services installed

Windows Mobile devices cannot use Certificate Web Enrollment Pages in Windows Server 2003 or in Windows Server 2008

Niestety, poprawki te nie są dostępne w polskiej wersji językowej, co wymaga dodatkowej pracy od administratora. No comments…