Ufanie niewiarygodnemu urzędowi certyfikacji - czy mogę ograniczyć sposób, w jaki system mu ufa?

32

(Wysłano do ServerFault zamiast StackOverflow, ponieważ uważam, że dotyczy to bardziej konfiguracji systemu operacyjnego niż kodu programowania).

Obecnie jestem odpowiedzialny za utrzymanie systemu, który łączy się z zewnętrzną usługą internetową. Ta usługa wymaga certyfikatów uwierzytelniania klienta, co jest uczciwe, ale sama usługa jest zabezpieczona certyfikatem z podpisem własnym utworzonym przez samodzielnie utworzony certyfikat głównego urzędu certyfikacji - ten sam katalog główny, który tworzy certyfikaty uwierzytelniania klienta.

Wystarczy tylko dodać bieżący certyfikat usługi do listy zaufanych i zignorować samodzielnie utworzony certyfikat urzędu, niestety certyfikat usługi zmienia się regularnie, więc certyfikat zaufania musi być zaufany, aby aplikacja nie uległa awarii, gdy certyfikat usługi został odnowiony.

Jednak nie (osobiście) ufam certyfikatowi CA na podstawie mojego doświadczenia z firmą prowadzącą serwis internetowy - nie zdziwiłbym się, gdyby wyciekł do sieci - i, co niepokojące, certyfikat CA nie ma żadnych ograniczeń dotyczących używania klucza it (chociaż zewnętrzne ataki MITM są możliwe, choć zdalne, bardziej martwię się o wyciek certyfikatu używanego na przykład do podpisywania kodu).

Czy mogę powiedzieć mojemu komputerowi (obecnie skrzynce serwerowej, ale w przyszłości zwykłym klientom klienckim), aby ufał urzędowi certyfikacji, ale tylko dla określonego zestawu zastosowań klucza i niewielkiego zestawu możliwych nazw podmiotów (nazw domen) )?

Serwer to obecnie system Windows Server 2012 R2, ale może on działać na komputerze z systemem Linux - choć wszystkie komputery stacjonarne to urządzenia z systemem Windows.

ssl-certificate certificate-authority x509 Dai
źródło
3
Przynajmniej w systemie Linux wiele aplikacji ma opcję określania lokalizacji certyfikatów równorzędnych urzędów certyfikacji, dzięki czemu można ograniczyć zakres tego urzędu certyfikacji tylko do aplikacji, która go używa. Odpowiedź @CryptoGuy działałaby również w systemie Linux, nie ma w tym nic specyficznego dla systemu Windows.
Edheldil
1
@Edheldil: Jest to jednak specyficzne dla implementacji - np. Windows obsługuje ograniczenia nazw X.509 znacznie dłużej niż np. NSS lub GnuTLS.
grawitacja
Twój system łączy się z tą usługą strony trzeciej; czy kod klienta w systemie można skonfigurować tak, aby ufał urzędowi certyfikacji tej usługi w taki sposób, że jest on wykonywany tylko dla tego kodu klienta , a nie dla całego systemu?
Castaglia
@Castaglia Mogę napisać własny kod weryfikujący certyfikat, który działa niezależnie od systemu hosta, ale istnieją inne elementy oprogramowania klienckiego, nad którymi nie mam kontroli, które używają ogólnosystemowych usług certyfikatów.
Dai

Odpowiedzi:

40

Tak to mozliwe. W przypadku systemu Windows istnieje funkcja o nazwie Cross-Certification lub Qualified Subordination.

Chodzi o to, że podpisujesz w swoim środowisku certyfikat CA wydany przez stronę trzecią. W rezultacie zdalny certyfikat SSL zostaje połączony z twoim własnym certyfikatem głównego urzędu certyfikacji. Aby uchronić się przed ewentualnymi nieuczciwymi certyfikatami, Name Constraintswdrażasz rozszerzenie certyfikatu, w którym określasz listę dopuszczalnych nazw. Jeśli CA wystawi certyfikat innej firmy (nieokreślony wyraźnie w rozszerzeniu Ograniczenia nazwy), zostanie on automatycznie odrzucony przez dostawcę CryptoAPI.

Oprócz ograniczeń nazw można opisać ograniczenie Ulepszonych zastosowań klucza, definiując Application Policiesrozszerzenie certyfikatu w certyfikacie krzyżowym. Twój dostawca zaufania pomyślnie zweryfikuje tylko zastosowania określone w Application Policiesrozszerzeniu.

Więcej informacji: Planowanie i wdrażanie certyfikacji krzyżowej i podporządkowania kwalifikowanego za pomocą systemu Windows Server 2003

ps, chociaż artykuł jest napisany przeciwko Windows Server 2003, artykuł nadal dotyczy najnowszej wersji systemu Windows Server.

Crypt32
źródło