К сожалению, API проверки CRL в OpenSSL не очень высокоуровневый, поэтому у вас есть код, который выполняет много операций самостоятельно.
Для краткого обзора того, что нужно:
- Извлечение URL-адреса CRL из сертификата для проверки из расширения точек распространения CRL. OpenSSL предоставляет функции парсинга сертификатов, но не имеет простого средства доступа к точкам распространения CRL
- Скачать CRL с URL. OpenSSL не реализует ни это, ни какую-либо форму кеширования.
- Проверка CRL (подпись, DN эмитента, срок действия, идентификатор ключа субъекта и т. Д.). OpenSSL предоставляет различные функции низкого уровня.
- Убедитесь, что серийный номер сертификата для проверки указан в CRL.
Конечно, это следует делать после проверки того, что сам сертификат «действителен» в том смысле, что он выдан доверенным (или заслуживающим доверия) ЦС, у него есть правильные расширения использования и что он (вместе со своим доверием цепь) в течение срока действия. OpenSSL имеет несколько функций низкого и среднего уровня, чтобы помочь с этим.
Некоторые дополнительные детали, которые могут усложнить реализацию полностью общей реализации:
- Некоторые сертификаты могут использовать OCSP вместо CRL.
- Некоторые сертификаты имеют DN или URL-адреса LDAP в качестве точек распространения.
- Некоторые CRL подписаны делегированным лицом, подписавшим CRL.
- Дельта-CRL или разделенные CRL могут усложнить реализацию (особенно кеширование w.r.t.)
- и т.д.
RFC 5280 описывает полный алгоритм проверки PKIX. Вам не нужно все реализовывать, но это хорошая справка, чтобы убедиться, что вы не забыли что-то важное. Вы должны посмотреть на модуль mod_ssl (содержащийся в сервере Apache httpd) для реализации, которая локально проверяет CRL и реализует проверку OCSP.
Если вы заранее знаете, каким ЦС вы доверяете (с точки зрения безопасности, это лучше), тогда вы можете получить задание cron, загружающее и обновляющее CRL. Это избавит вас от реализации части о поиске / загрузке / кэшировании CRL внутри вашей программы.