Почему Windows certutil и openSSL отображают байты подписи CSR (pkcs#10) по-разному?

Почему Windows certutil и openSSL отображают байты подписи CSR (pkcs#10) по-разному?

Я выполнил эту команду в Windows: certutil -dump [p10_filename]

выход:

PKCS10 Certificate Request:
Version: 1
Subject: <*** REMOVED ***>
...
Signature Algorithm:
    Algorithm ObjectId: 1.2.840.113549.1.1.4 md5RSA
    Algorithm Parameters:
    05 00
Signature: UnusedBits=0
    0000  ff 9d 4b 25 15 ae 79 32  66 7b 9f 4e a4 17 1e f8
    0010  3a 64 69 f5 99 a3 7b 8e  c2 ee 2d 61 ef ec 78 c9
    0020  9d bb 10 b3 60 36 96 f6  a0 3f 85 c4 3b 2e 16 25
    0030  52 d9 81 a1 aa 56 d0 54  6c 28 12 7f 64 2d cd 1b
    0040  83 3c 03 ad 74 27 02 a1  55 42 d5 12 8e dd dc cf
    0050  a7 42 43 76 7d aa 47 d2  3e 62 b8 30 a3 83 1d 8b
    0060  61 7f f4 9e ba f3 bd b6  d2 28 9b 5a b9 b1 38 06
    0070  d4 42 85 91 64 d3 9d 6d  6a c4 3c f7 3b 6e 93 0a
    0080  a8 b2 fd 2f 3e f5 ed fd  fa a3 d0 d9 7a b6 71 96
    0090  d9 03 be 32 d9 70 9d 5a  f2 4a 5f db df 2a 8b cd
    00a0  12 d9 71 29 e2 93 73 51  a0 ca f2 3c c8 b1 38 87
    00b0  16 67 23 2e 2a 96 45 8f  fe eb 8c 01 d7 b9 2e 3e
    00c0  e6 7e 08 71 3b 5a ca 6a  23 29 73 49 88 84 1f 21
    00d0  3b 83 ce 77 55 a3 31 fa  d2 b5 61 c2 53 39 9b bc
    00e0  e2 1d db d1 1b f7 27 a6  81 43 d2 c7 c8 f3 75 ad
    00f0  3e 37 23 de 34 b3 8a 57  be 11 22 ef 4c c2 81 2f
Signature matches Public Key
Key Id Hash(rfc-sha1): 4e 6c d8 61 0c 91 a2 4a 07 ed af ae 05 c9 fb 95 cd c9 cc 7e
Key Id Hash(sha1): b7 63 38 21 9e 21 6a 82 eb bb a4 8e bc 68 5c 6f 07 a9 72 07
CertUtil: -dump command completed successfully.

Когда я выполнил ту же команду в openssl, я получил другой результат?

openssl req -in <csr_filename> -noout -text

Certificate Request:
    Data:
        Version: 0 (0x0)
.... clipped ...

    Signature Algorithm: md5WithRSAEncryption
         2f:81:c2:4c:ef:22:11:be:57:8a:b3:34:de:23:37:3e:ad:75:
         f3:c8:c7:d2:43:81:a6:27:f7:1b:d1:db:1d:e2:bc:9b:39:53:
         c2:61:b5:d2:fa:31:a3:55:77:ce:83:3b:21:1f:84:88:49:73:
         29:23:6a:ca:5a:3b:71:08:7e:e6:3e:2e:b9:d7:01:8c:eb:fe:
         8f:45:96:2a:2e:23:67:16:87:38:b1:c8:3c:f2:ca:a0:51:73:
         93:e2:29:71:d9:12:cd:8b:2a:df:db:5f:4a:f2:5a:9d:70:d9:
         32:be:03:d9:96:71:b6:7a:d9:d0:a3:fa:fd:ed:f5:3e:2f:fd:
         b2:a8:0a:93:6e:3b:f7:3c:c4:6a:6d:9d:d3:64:91:85:42:d4:
         06:38:b1:b9:5a:9b:28:d2:b6:bd:f3:ba:9e:f4:7f:61:8b:1d:
         83:a3:30:b8:62:3e:d2:47:aa:7d:76:43:42:a7:cf:dc:dd:8e:
         12:d5:42:55:a1:02:27:74:ad:03:3c:83:1b:cd:2d:64:7f:12:
         28:6c:54:d0:56:aa:a1:81:d9:52:25:16:2e:3b:c4:85:3f:a0:
         f6:96:36:60:b3:10:bb:9d:c9:78:ec:ef:61:2d:ee:c2:8e:7b:
         a3:99:f5:69:64:3a:f8:1e:17:a4:4e:9f:7b:66:32:79:ae:15:
         25:4b:9d:ff

Я открыл файл в текстовой панели с помощью HEX-EDITOR, и openSSL кажется правильными необработанными данными? Возможно, это какая-то разница в кодировке? Или какая-то оболочка, которую certutil использует для отображения данных, которые не показывает openSSL?


openssl digital-signature csr pki certutil
person atom88    schedule 12.12.2014    source источник
comment
Вы видели, что презентации содержат одни и те же байты, записанные в обратном порядке, не так ли?   -  person mkl    schedule 13.12.2014
comment
Спасибо, я не заметил, что это тот же HEX, написанный наоборот. Я предполагаю, что небольшая разница Endian/Big Endian объясняет это.   -  person atom88    schedule 15.12.2014
comment
Да, это действительно так.   -  person mkl    schedule 15.12.2014
comment
Stack Overflow — это сайт для вопросов по программированию и разработке. Этот вопрос кажется не по теме, потому что он не о программировании или разработке. См. раздел О каких темах я могу задать здесь в Справочном центре. Возможно, Суперпользователь или Unix & Linux Stack Exchange лучше спросить.   -  person jww    schedule 13.09.2017
comment
Речь идет о программировании и разработке, когда вам нужно программировать интерфейс PKCS#10 и получать разные результаты. Я должен был знать, какой дисплей правильный.   -  person atom88    schedule 01.11.2017

Ответы (1)


arrow_upward
2
arrow_downward

Microsoft API обычно кодирует/декодирует числа как значения с прямым порядком байтов. Однако для подписей указан точный порядок, и официально это даже не число. См. RSA PKCS#1 v2.1 и I2OSP в частности. I2OSP кодирует целочисленное значение (любого размера) как число со статическим размером big endian. Это также отражается тем фактом, что число находится в БИТОВОЙ СТРОКЕ, а не в ЦЕЛОМ ASN.1.

Таким образом, представление Microsoft неверно. Конечно, требуется рассматривать подпись как число, чтобы делать с ней что-либо значимое, поэтому вполне вероятно, что Microsoft сначала преобразует подпись в число, а затем просто отображает число в шестнадцатеричном формате, используя собственное внутреннее представление с прямым порядком байтов. Таким образом, значение подписи то же самое, байты просто перевернуты, так что вы видите зеркальное отражение подписи.

person Maarten Bodewes    schedule 13.12.2014
comment
Спасибо, Мартен, я не заметил, что это тот же HEX, написанный наоборот. Я предполагаю, что небольшая разница Endian/Big Endian объясняет это. - person atom88; 15.12.2014