Czy można ufać certyfikatowi w systemie Windows, nie ufając jego głównemu urzędowi certyfikacji?

Czy możliwe jest uzyskanie od systemu Windows zaufania do certyfikatu bez zaufania do głównego urzędu certyfikacji jako zaufanego głównego urzędu certyfikacji?

powiedz, że mam następujący łańcuch certyfikatów,

Dept-Root-CA
Dept-Intermediate-1
Server-Certificate

Chcę zaufać certyfikatowi serwera, ale nie chcę ufać Dept-Root-CA, ponieważ wtedy mógłby podpisać dowolny certyfikat, a moje serwery mu zaufałyby. To, że jestem gotów zaufać certyfikatowi na certyfikacie serwera dla konkretnej operacji, nie oznacza, że jestem gotów zaufać, że Dept-Root-CA został odpowiednio zabezpieczony.

dzięki

windows ssl

— bkr
źródło

Na czym dokładnie chcesz zaufać? HTTPS? A może coś jeszcze? Tam są sposoby wskazując, że chcesz zaakceptować pojedynczy certyfikat bez zapisywania czegokolwiek innego z głównego urzędu certyfikacji, ale to zależy od tego, co robisz. (Nadal będziesz otrzymywać błędy, jeśli spróbujesz zweryfikować certyfikat)

— Mark Henderson

Zasadniczo tak. Gdyby to był niestandardowy kod, nie byłby to problem - ale to używa ADFS 2 i jedyne, co mogę zrobić w odniesieniu do tego, jak traktuje certyfikaty, to zmienić sposób, w jaki serwer ufa temu certyfikatowi. Są też inne przypadki, ale to tylko obecny przykład.

— bkr

Odpowiedzi:

Nie. Tak długo, jak certyfikat zawiera „Wydane przez: xxx”, musisz również ufać xxx, aż do samego końca łańcucha. Jeśli jest to samopodpisany certyfikat, można go umieścić w sklepie Zaufane główne urzędy certyfikacji, a ponieważ jest on wystawiany i wydawany przez ten sam podmiot, należy mu zaufać.

Jednak nie jest to całkowicie wykonalne lub wskazane, aby całkowicie ominąć cały cel bezpieczeństwa opartego na certyfikatach.

— Ryan Ries
źródło

Bałam się tego. Nie nazwałbym tego jednak obchodzeniem. To, że chcę, aby bezpieczny kanał rozmawiał z komputerem w innej grupie organizacyjnej, nie oznacza, że chcę zaufać ich urzędowi certyfikacji.

— bkr

Racja ... ale urząd certyfikacji podpisał ten certyfikat, a bez tego certyfikatu CA drugi koniec może po prostu zmieniać swój certyfikat.

— SpacemanSpiff

Nie jestem pewien, czy rozumiem, co mówisz. Chcę wyraźnie zaufać ich certyfikatowi. Gdyby zostało zmienione, chciałbym ponownie wyraźnie mu zaufać. Zasadniczo chcę model zaufania certyfikatu, tak jak w Firefoksie. W przeglądarce Firefox, jeśli certyfikat nie jest ważny w istniejących zaufanych urzędach certyfikacji, możesz mimo to zaufać - jeśli się zmieni, będziesz musiał zaufać nowemu certyfikatowi, ponieważ nie został on wyraźnie zaufany.

— bkr

just keep changing their certificateJeśli zdalny koniec zmieni ich certyfikat, nie będzie pasował do tego, który zapisałeś. Jeśli zignorujesz całą działalność urzędu certyfikacji, nie traktujesz jej jak kluczy hosta SSH.

— Zoredache

realistycznie zmieniają to tylko raz na 2 lata. produkt MS, którego używam, wymaga zabezpieczenia połączenia przez https. więc trzeba mu zaufać. ponieważ jest podpisany z ich urzędem certyfikacji, musiałbym zaufać ich urzędowi certyfikacji - nie chcę tego robić, ponieważ pozwoliłoby im to na sfałszowanie dowolnego certyfikatu na moim serwerze, w przeciwieństwie do ograniczonej interakcji z określoną nazwą hosta.

— bkr

Dobrze .... Ty mógł uchwycić te informacje ufność w inny sposób.

Jest to niestety trochę skomplikowane.

Utwórz własny urząd certyfikacji, a następnie utwórz wystawcę podpisu krzyżowego dla Dept-Intermediate-1 (lub Dept-Root-CA), podpisując ich certyfikat z urzędem certyfikacji, ewentualnie dodając ograniczenia domen. Jeśli „rzeczywisty” Dep-Intermediate-1 zostanie dezaktywowany (najlepiej) lub nieznany, system Windows zamiast tego użyje łańcucha zaufania.

Zobacz moją drugą odpowiedź tutaj: Ogranicz certyfikat główny do domeny

Tak powinny działać certyfikaty, wykorzystując podpisy cyfrowe do potwierdzenia posiadania klucza. Ponieważ chcesz potwierdzić certyfikat, a klucz należy do serwera, podpisz go sam, pod swoim zwierzchnictwem, a następnie powiedz systemowi, aby ci zaufał.

W certyfikacie bez hierarchii urzędu certyfikacji nadal jest wiele narzędzi , które przekraczają to, co zapewniają klucze SSH; częścią tego są ograniczenia na nich. Użycie klucza, daty ważności, informacje o odwołaniu, ograniczenia domen itp. Drugą częścią są informacje identyfikujące; serwer, który jest właścicielem klucza, tożsamość emitenta, egzekwowane zasady CA, informacje o przechowywaniu kluczy itp.

— davenpcj
źródło

To jest interesujące. Będę musiał znaleźć trochę czasu, aby spróbować przejść przez ten proces i sprawdzić, czy dam radę.

— bkr