Piszki Lab

Analiza przypadku w języku przodków…

Horizon Workspace: Manualna analiza łańcucha certyfikatów

| 0 comments

Nadszedł dzień w którym postanowiłem wystawić na świat naszą laboratoryjną instalację Horizon Workspace. Zaopatrzyłem się w certyfikat typu wildcard wystawiony przez Rapid SSL (GeoTrust), stworzyłem odpowiedni plik “chain” i przystąpiłem do działania. Oczywiście w przypadku Horizon Workspace nic nie jest proste, jeśli chodzi o zmianę FQDN i wgranie nowych certyfikatów SSL dla gateway-va. Już na wstępie zderzyłem się z błędem “Certificate does not chain up to root”.

ssl1

Zaglądamy zatem do logu configurator-va:/opt/vmware/horizon/configuratorinstance/logs/configurator.log

ssl2

Do weryfikacji certyfikatu użyty jest skrypt verifyCert.hzn, a po jego przejrzeniu okazuje się, że użyta zostaje komenda OpenSSL:

openssl verify -purpose sslserver -CApath /dev/null –CAfile ho.pl ho.pl (plik ho.pl to mój chain wgrany do katalog temp).

Rozszerzamy polecenie o tryb verbose i sprawdzamy rezultat:

ssl3

Wychodzi na to, że źle jest skonstruowany łańcuch certyfikatów, certyfikat pośredniczący jest zły, zamiast Rapid SSL CA, wstawiłem Geotrust SSL CA. Poprawiam łańcuch i sprawdzam ponownie:

ssl4

ssl5

Dostajemy komunikat “error 2 at 1 depth lookup:unable to get issuer certificate” co przekłada się na “Error validating custom certificate”. Wychodzi na to, że brakuje kolejnego certyfikatu, ale jak to możliwe? Łańcuch odpowiada dokładnie tej ścieżce:

ssl7

Po chwili zastanowienia, sprawdzam certyfikat GeoTrust Global CA i wychodzi na to, że to też jest certyfikat pośredniczący! Jego łańcuch przedstawia się następująco:

ssl8

Dodaję certyfikat GeoTrust (Equifax Secure CA) do pliku łańcucha certyfikatów i sprawdzam ponownie:

ssl6

Działa! A więc prawidłowy łańcuch dla certyfikatu wystawionego w Rapid SLL to:

4. *.pulab.pl

3. RapidSSL CA

2. GeoTrust Global CA

1. GeoTrust

Pierwszy raz spotkałem się z sytuacją w której system Windows podaje niekompletną ścieżkę certyfikatu, najwyraźniej GeoTrust Global CA ma w Microsofcie bardzo duży poziom zaufania.

Przypominam, że prawidłowa konstrukcja pliku łańcucha certyfikatów przedstawia się następująco:

—–BEGIN CERTIFICATE—–
Thumbprint Server Certificate
—–END CERTIFICATE—–
—–BEGIN CERTIFICATE—–
Thumbprint Intermediate(2) CA Server
—–END CERTIFICATE—–
—–BEGIN CERTIFICATE—–
Thumbprint Intermediate(1) CA Server
—–END CERTIFICATE—–
—–BEGIN CERTIFICATE—–
Thumbprint Root CA Server
—–END CERTIFICATE—–

English

Oceń ten artykuł:
[Total: 0 Average: 0]

Dodaj komentarz

Required fields are marked *.