Отмяната на сертификати се проваля: кой хост до какво не достига

Сертификатите могат да са в рамките на срока си на валидност, докато VPN все още съобщава за грешка при удостоверяване, и някой заключава, че сертификатът е отменен. Това са три различни факта. Данните за отмяна трябва да бъдат изтеглени от устройството, което извършва валидирането, от точка за публикуване, посочена вътре в самия сертификат. Когато това устройство не може да достигне до точката, проверката се проваля по причини, несвързани със статуса на сертификата.

Пътят за изтегляне принадлежи на валидатора

Започнете с идентифициране на валидатора. Когато лаптоп проверява сертификата на шлюза, изтеглянето се извършва от лаптопа; когато шлюзът проверява клиентски сертификат, го прави шлюзът. Услуга за удостоверяване на заден план може да добави трети валидатор със собствено мрежово положение. Всеки има различен маршрут към интернет и различна конфигурация на прокси. Доказателствата, събрани на работната станция на администратора, не казват нищо за сървър в DMZ.

Запишете сертификата, валидатора, времето на опита и точния код на състояние, преди да промените каквото и да е.

Прочетете точката за публикуване от сертификата

Сертификатът посочва къде живее статусът му. Четете тези полета, вместо да гадаете адрес на CA.

openssl x509 -in gateway.cer -noout -text | grep -A3 "CRL Distribution Points"
openssl x509 -in gateway.cer -noout -text | grep -A2 "Authority Information Access"

Първото разширение изброява точки за разпространение на CRL, а второто изброява методи за достъп до информация за издателя, които могат да покриват статус по OCSP и изтегляне на сертификата на издателя. Това са различни механизми и OCSP отговорникът не е CRL файл. Хостът за публикуване често е обикновен уеб сървър, а не машината на CA, защото офлайн издател може да подпише CRL, който друг сървър разпространява. Затова правило в защитна стена, описано като достъп до CA, е твърде неясно, за да бъде внедрено или прегледано.

Тествайте изтеглянето от устройството, което валидира

Изпълнете теста за изтегляне в средата, която действително извършва валидиране, с одобрен сертификатен материал и без частни ключове.

certutil -urlfetch -verify .\client-test.cer
curl -sS -o /dev/null -w "%{http_code}\n" http://crl.example.com/ca.crl

Изпълнението на certutil проверява веригата и съобщава кои изтегляния на URL са успешни или неуспешни, докато извикването на curl тества един адрес за публикуване от същия хост и връща само код на състояние. Неуспешно изтегляне от достъпен адрес сочи към проблеми със съдържанието или подписа; грешка при свързване сочи към маршрутизация, DNS или прокси. Запазете и двата резултата, защото едно успешно изтегляне не доказва, че цялата верига е използваема. Сменете примерния хост и път с точката за разпространение, намерена в сертификата.

Отделете липсващите данни от отменения статус

Четири изхода изглеждат сходно отвън: точката е недостъпна, списъкът е остарял, списъкът е подписан от грешен издател или сертификатът наистина е отменен. Само последният е резултат за статус и само той оправдава премахване на достъп. Кеширането усложнява картината допълнително, тъй като по-рано изтеглени данни могат да скрият счупен път за публикуване до следващото обновяване. Изключването на проверката за отмяна, изтриването на несвързани сертификати или рестартирането на шлюза заменят диагнозата с активност.

След поправката принудете ново удостоверяване и потвърдете, че желаното изтегляне на статус успява. Където има контролирана тестова идентичност, потвърдете, че тя все още се отхвърля, защото достъпност, която премахва проверката, не е ремонт.