Цифровой сертификат и расширения

Изначально сертификат содержал только подписанный публичный ключ и ссылку на удостоверяющий центр (RFC 1422, 1993 г.):

   1.  version
   2.  serial number
   3.  signature (algorithm ID and parameters)
   4.  issuer name
   5.  validity period
   6.  subject name
   7.  subject public key (and associated algorithm ID)

Этого недостаточно для практического использования сертификатов. Например, как отличить сертификат сервера от сертификата удостоверяющего центра? Как запретить подписывать код сертификатом для аутентификации сервера? Как использовать один сертификат для нескольких серверов? Кого спрашивать, не скомпрометирован ли сертификат?

Ограничения базовых сертификатов были известны с самого начала, и уже в 1996 г. были выпущены новые стандарты. Были стандартизованы протоколы проверки отзыва сертификатов (CRL и OCSP) и дополнительные поля в сертификатах. Эти стандарты получили название "расширения". Сейчас актуальным является третья версия, стандартизована в RFC 5280 (2008 г.)

На практике наиболее часто используемыми расширениями являются Key Usage, Subject Alternative Names, Basic Constraints поля, связанные с проверкой отзыва сертификата, например URL сервиса OCSP удостоверяющего центра (например, Authority Information Access)

Что с ними делать - зависит от того, что вы собираетесь делать. Если вы просто используете сертификаты для аутентификации клиентов и серверов, и пользуетесь сторонней библиотекой для их валидации, это один сценарий. И совсем другое дело, если вы пишете собственную криптографическую систему.