Получение строк ASN.1 эмитента из файлов PEM?

Question

Недавно я столкнулся с проблемой с Windows 2003 (видимо, она также существует и в других версиях), где, если сервер SSL/TLS запрашивает аутентификацию сертификата клиента и имеет более 16 КБ доверенных сертификатов, Internet Explorer (или любой другой другое приложение, использующее schannel.dll) не может выполнить SSL-квитирование. (Вкратце, сервер разбивает сообщение на куски размером 2^14 байтов, согласно RFC 2246 с. 6.2.1, но Schannel не был написан для поддержки этого. У меня есть подтверждение от поддержки Microsoft, что это недостаток в Schannel и что они рассматривают возможность его фиксации в будущей версии.)

Итак, я пытаюсь найти способ легко проанализировать мои доверенные сертификаты (я использую Apache как мой сервер, поэтому все они в формате PEM), чтобы получить полную длину DNN в формате ASN.1 (так, как они отправляются по кабелю во время рукопожатия), и, таким образом, убедитесь, что я слишком близко к пределу. Я еще не смог найти способ сделать это: функция OpenSSL asn1parse приближается, но, похоже, она не дает способа получить последовательность ASN.1 только для имени эмитента, что и есть Мне нужно.

Любые предложения?

Answer 1

Поскольку ASN.1 описывает себя, довольно легко написать парсер ASN.1. Как вы, наверное, знаете, данные ASN.1 содержат дерево значений, где каждый тип значения идентифицируется глобально назначенным OID (Object ID). Вы можете найти бесплатный ASN.1-декодер с исходным кодом по адресу: http://www.geocities.co.jp/SiliconValley-SanJose/3377/asn1JS.html. Это написано на javascript, чтобы вы могли играть с ним прямо в своем браузере.

Как ваш точный вопрос - я бы:

1. Используйте прилагаемый парсер, найти еще один или написать мой собственный
2. Найти OID доверенных DNs (проверить спецификацию или просто декодировать сертификата с помощью прилагаемая страница-декодер ASN.1)
3. Объедините два выше, чтобы извлечь размер доверенных DN внутри сертификата.

Answer 2

openssl asn1parse сделает это, но вам нужно будет провести ручную разборку, чтобы выяснить, где начинается последовательность эмитентов. В RFC 5280 это 4-й элемент в последовательности TBSCertificate (потенциально 3-й, если это сертификат v1), сразу после алгоритма подписи. В следующем примере:

0:d=0 hl=4 l= 621 cons: SEQUENCE 
    4:d=1 hl=4 l= 470 cons: SEQUENCE 
    8:d=2 hl=2 l= 3 cons: cont [ 0 ] 
    10:d=3 hl=2 l= 1 prim: INTEGER   :02 
    13:d=2 hl=2 l= 1 prim: INTEGER   :02 
    16:d=2 hl=2 l= 13 cons: SEQUENCE 
    18:d=3 hl=2 l= 9 prim: OBJECT   :sha1WithRSAEncryption 
    29:d=3 hl=2 l= 0 prim: NULL 
    31:d=2 hl=2 l= 64 cons: SEQUENCE 
    33:d=3 hl=2 l= 11 cons: SET 
    35:d=4 hl=2 l= 9 cons:  SEQUENCE 
    37:d=5 hl=2 l= 3 prim:  OBJECT   :countryName 
    42:d=5 hl=2 l= 2 prim:  PRINTABLESTRING :US 
    46:d=3 hl=2 l= 26 cons: SET 
    48:d=4 hl=2 l= 24 cons:  SEQUENCE 
    50:d=5 hl=2 l= 3 prim:  OBJECT   :organizationName 
    55:d=5 hl=2 l= 17 prim:  PRINTABLESTRING :Test Certificates 
    74:d=3 hl=2 l= 21 cons: SET 
    76:d=4 hl=2 l= 19 cons:  SEQUENCE 
    78:d=5 hl=2 l= 3 prim:  OBJECT   :commonName 
    83:d=5 hl=2 l= 12 prim:  PRINTABLESTRING :Trust Anchor 
    97:d=2 hl=2 l= 30 cons: SEQUENCE 
    99:d=3 hl=2 l= 13 prim: UTCTIME   :010419145720Z 
    114:d=3 hl=2 l= 13 prim: UTCTIME   :110419145720Z 
    129:d=2 hl=2 l= 59 cons: SEQUENCE 

ДН Эмитент начинается по смещению 31 и имеет длину заголовка из двух и длину значения из 64, для общей длины 66 байт. Это, конечно, не так просто для написания сценария ...