Невозможно загрузить CSR/ Сертификаты в Open Banking Directory

Question

У меня появляется эта ошибка, когда я пытаюсь загрузить запрос сертификата в Open Banking Directory как сертификат подписи OB.

Когда я копирую сообщение, мне дают это сообщение;

Когда я проверяю сетевые запросы, кажется, что он показывает внутреннюю ошибку сервера (ответ 500) и возвращает graphql. Это ответ:

{"errors":[{"message":"Error: Request failed with status code 400","locations":[{"line":2,"column":3}],"path":["addCertificate"]}],"data":null}

Была ли эта проблема с кем-либо раньше? Я сгенерировал CSR с Open SSL со своими учетными данными с этой командой:

openssl req -new -newkey rsa:2048 -nodes -out [STATEMENT_CLIENT_ID].csr -keyout [STATEMENT_CLIENT_ID].key -subj "/C=GB/ST=/L=/O=OpenBanking/OU=[ORGANISATION_ID]/CN=[STATEMENT_CLIENT_ID]" -sha256

Теги в фигурных скобках отредактированы. Я также попробовал докер, но безуспешно. Я все уши к любым решениям, которые приходят мне на пути.

Спасибо за уделенное время.

Answer 1

Решили эту проблему, создав CSR на OpenSSL с соответствующими файлами конфигурации. Форматирование eiDAS имеет важное значение.

Команды:

req -new -config "obseal.cnf" -out "Seal.csr" -keyout "SealPrivateKey.key"

req -new -config "obwac.cnf" -out "WAC.csr" -keyout "WACPrivateKey.key"

Answer 2

Согласно приведенному выше вопросу Бентейлора, у OBWAC и OBSEAL есть скрытая жемчужина в своем составе в виде QCStatements, которые сопоставляют роли, указанные в утверждении программного заявления, с ролями, которые результирующие сертификаты от CSR указали в своих qcStatementOID. Вот пример CNF для OBSEAL:

[ req ]
default_bits            = 2048
encrypt_key             = no
default_md              = sha256
default_keyfile         = obseal.key
utf8                    = yes
string_mask             = utf8only
prompt                  = no
distinguished_name      = client_dn
req_extensions          = client_reqext

[ client_dn ]
countryName             = "GB"
organizationName        = "Typical O name"

# Subject common name
commonName              = "<Open Banking Directory Org ID>"

[ client_reqext ]
keyUsage                = critical,digitalSignature,nonRepudiation

subjectKeyIdentifier    = hash

qcStatements=DER:30713013060604008e4601063009060704008e46010602305a06060400819827023050303930110607040081982701020c065053505f504930110607040081982701030c065053505f414930110607040081982701040c065053505f49430c0c4f70656e2042616e6b696e670c0547422d4f42

Если вы вставите приведенный выше двоичный код в декодер ASN1, вы увидите следующую структуру:

SEQUENCE (2 elem)
  SEQUENCE (2 elem)
    OBJECT IDENTIFIER 0.4.0.1862.1.6
    SEQUENCE (1 elem)
      OBJECT IDENTIFIER 0.4.0.1862.1.6.2
  SEQUENCE (2 elem)
    OBJECT IDENTIFIER 0.4.0.19495.2
    SEQUENCE (3 elem)
      SEQUENCE (3 elem)
        SEQUENCE (2 elem)
          OBJECT IDENTIFIER 0.4.0.19495.1.2
          UTF8String PSP_PI
        SEQUENCE (2 elem)
          OBJECT IDENTIFIER 0.4.0.19495.1.3
          UTF8String PSP_AI
        SEQUENCE (2 elem)
          OBJECT IDENTIFIER 0.4.0.19495.1.4
          UTF8String PSP_IC
      UTF8String Open Banking
      UTF8String GB-OB

Узлы PSP_* сопоставьте сертификаты OBWAC/OBSEAL с ролями программных операторов, как представляется, следующим образом:

• PSP_PI знак равно PISP
• PSP_AI знак равно AISP
• PSP_IC знак равно CBPII

Вы можете использовать редактор ASN1 для редактирования / удаления узлов и получения двоичного файла, как требуется для OBWAC и OBSEAL. Просто вставьте двоичный файл безqcStatement=DER:расстаться и покончить с этим. Вы также можете просмотреть структуру qcStatement, используя этот веб-сайт.

Еще одно замечание: в отличие от сертификата eIDAS QSeal, максимальная длина ключа для OBSEAL кажется 2048 биты.

Надеюсь, кто-то сочтет это полезным, поскольку британские банки начинают отказываться от старых ключей подписи / транспорта Open Banking и вместо этого внедряют eIDAS/OBWAC+SEAL. Удачи и пусть начинается самое интересное. o7

Answer 3

У меня такая же проблема на данный момент в производственной песочнице, и открытый банкинг не показывает никаких соответствующих ошибок.

Использование версии OpenSSL: OpenSSL 1.1.1g 21 апреля 2020 г. И следующее здесь, которое появляется над полем загрузки.

И перейдите по этой ссылке в формате PDF для документации, которая появляется над полем загрузки.

      [ req ] 
default_bits = 2048 
encrypt_key = yes 
default_md = sha256 
utf8 = yes 
string_mask = utf8only 
prompt = no 
distinguished_name = client_dn 
req_extensions = client_reqext 

[ client_dn ] 
countryName = "GB" 
organizationName = "My bank Ltd" 
organizationIdentifier = "OBGBR-GB-Unknown1315H25731lXE8ZIEM" 
commonName = "Unknown1315H25731lXE8ZIEM" 

[ client_reqext ] 
keyUsage = critical,digitalSignature,nonRepudiation 
subjectKeyIdentifier = hash 

qcStatements=DER:3081813013060604008e4601063009060704008e46010603306a06060400819827023060303930110607040081982701010c065053505f415330110607040081982701020c065053505f504930110607040081982701030c065053505f41490c1b46696e616e6369616c20436f6e6475637420417574686f726974790c0647422d464341

Различия, которые я вижу, связаны с определениемorganizationIdentifier. В документах показано, как определить его, если используется инструмент, который его не поддерживает, но текущая версия OpenSSl поддерживает. Итак, при печати с помощью:

      openssl asn1parse -in obwac.csr -inform PEM

Пример в пдф:

      66:d=5 hl=2 l= 3 prim: OBJECT :2.5.4.97 
71:d=5 hl=2 l= 34 prim: UTF8STRING :PSDGB-OB-Unknown1315H25731lXE8ZIEM

Новая версия OpenSSL:

         66:d=5  hl=2 l=   3 prim: OBJECT            :organizationIdentifier
   71:d=5  hl=2 l=  34 prim: UTF8STRING        :OBGBR-GB-Unknown1315H25731lXE8ZIEM