Generowanie Żądania certyfikatu z openssl dla Microsoft Enterprise CA

Dawno temu pisałem o tym, jak wygenerować żądanie certyfikatu dla systemów nie będących Windowsami tak, aby dało się certyfikat wystawić na Microsoft Enterprise CA. Jako przykład podałem generowanie certyfikatów serwera vCenter
Niedawno temat powrócił, ale w nowej odsłonie, gdyż serwer vSphere wymaga zdefiniowania w certyfikacie odpowiednich Nazw Alternatywnych. Powstało pytanie, jak pogodzić te dwie funkcjonalności.
Okazuje się to być całkiem proste, trzeba tylko pamiętać, że choć plik konfiguracji openssl pozwala na wiele sekcji opisujących rozszerzenia żądania certyfikatu, to tylko jedna z nich może być wykorzystywana w trakcie generowania certyfikatu. Dlatego przygotowując plik konfiguracyjny dla określonego serwera warto uporządkować jego strukturę, względem propozycji przedstawionej w poprzednim wpisie.
Przykładowy plik konfiguracyjny może wyglądać następująco:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
openssl_conf = openssl_init

[ openssl_init ]
oid_section = new_oids

[ req ]
default_bits = 2048
default_keyfile = rui.key
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req

[ new_oids ]
MsCaCertificateTemplate = 1.3.6.1.4.1.311.20.2

[ v3_req ]
basicContraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:server01, DNS:server01.domena.test
MsCaCertificateTemplate = ASN1:PRINTABLESTRING:VMwareCertificate

[ req_distinguished_name ]
countrName = PL
stateOrProvinceName = Malopolskie
localityName = Krakow
0.organizationName = Firma
organizationalUnitName = Oddzial
commonName = server01.domena.test

Analizując najważniejsze części:

  • Linia 1. Wskazuje na sekcję będącą konfiguracją globalną.
  • Linia 4. Wskazuje na sekcję defniującą OIDy. Linia ta jest jedyną w sekcji konfiguracji globalnej
  • Linia 13. Wskazuje na sekcję definiującą rozszerzenia, które zostaną dodane do żądania certyfikatu
  • Linia 15. Definiuje sekcję z OIDami.
  • Linia 16. Definiuje OID zarejestrowany i użytkowany przez Microsoft do oznaczania rozszerzenia definiującego szablon certyfikatu
  • Linia 22. Definiuje alternatywne nazwy serwera. Należy zwrócić uwagę na fakt, że w przykładzie używany jest prefiks DNS: Możliwe są także inne prefiksy.
  • Linia 23. Definiuje nazwę używanego szablonu certyfikatów. Należy zwrócić uwagę, że wykorzystywany jest wariant nazwy bez żadnych spacji. Nazywa się on „Certificate Template Name”, w przeciwieństwie do nazwy przyjaznej, nazywającej się „Certificate Template Display Name”

Pozostała cześć jest standardowa dla każdego żądania obsługiwanego przez openssl.

VMware ESX – failed to install Virtual Center Agent

Błąd który zyskał dzisiaj swojego posta może mieć masę przyczyn. Skupię się na tej, która mnie spotkała po raz kolejny, tak na prawdę tylko dlatego, że wcześniej o niej tu nie napisałem. Postanawiam się poprawić i więcej nie przestawać pisać. 🙂
Mianowicie jedną z możliwości powstania tego komunikatu jest nie sam błąd w procesie przetwarzania rpm’a, lecz sama kwestia uruchomienia nowego procesu vpx. Należy jednak nie sugerować się faktem że komenda

1
 service vmware-vpxa restart

wykonuje się poprawnie. Podobnie, nie należy szukać przyczyny wnioskując po poszlace występującej w

1
 /var/log/messages

.
Problemem jest w tym wypadku niewłaściwy format certyfikatu. Niestety. VMware nie uzna standardowego, powszechnego formatu PEM, takiego jaki „wypluwają” wszystkie urzędy certyfikacji. Żeby ustawić swój własny, dopasowany do istniejącego środowiska certyfikat należy najpierw z formatu PEM skonwertować go do tak zwanej tekstowej reprezentacji PEM:

1
 openssl x509 -text -in /etc/vmware/ssl/rui.crt -out /etc/vmware/ssl/rui.crt

Szansą na diagnozę tej pomyłki jest interpretacja mało znanego pliku logów

1
 /var/log/vmware/vpxa.log

. w Przypadku tego błędu jest tam informacja o niemożności interpetacji pliku z certyfikatem. Należy dodać, że przy diagnozie innych problemów z komunikacją ESX’a z vCenter ten plik logów też może być pomocny.