self-signed certificate in chain. Ошибка часто встречается, а выявлять самоподписанные серты в цепочке я не умею. Причём это на моей стороне или на стороне API (Сбер Студио), я не знаю.
Решил обойти, встроив RejectUnauthorized флаг в поле httpsAgent Axios'а:
export function UnsafeRequestInterceptor(config: InternalAxiosRequestConfig) {
const url = config.url;
if (url.includes(CUSTOM_ROUTES[0])) {
config.httpsAgent = new https.Agent({
...config.httpsAgent,
rejectUnauthorized: false,
});
}
return config;
}
Но выходит ошибка, Axios просто выплёвывает в качестве ошибки свой request, и всё! Самой ошибки и её описания я не вижу! В чём проблема? Это точно ошибка, так как она валится в catchError.
Вот pastebin с request'ом: https://pastebin.com/PFzc2NMB
По ходу, это сберовская шняга. Сделал запрос: openssl s_client -connect ngw.devices.sberbank.ru:9443 -showcerts Ну а там: CONNECTED(00000003) depth=2 C = RU, O = The Ministry of Digital Development and Communications, CN = Russian Trusted Root CA verify error:num=19:self signed certificate in certificate chain verify return:1 depth=2 C = RU, O = The Ministry of Digital Development and Communications, CN = Russian Trusted Root CA verify return:1 depth=1 C = RU, O = The Ministry of Digital Development and Communications, CN = Russian Trusted Sub CA verify return:1 depth=0 C = RU, ST = Moscow, L = Moscow, O = Sberbank of Russia PJSC, CN = ngw.devices.sberbank.ru verify return:1 --- Certificate chain 0 s:C = RU, ST = Moscow, L = Moscow, O = Sberbank of Russia PJSC, CN = ngw.devices.sberbank.ru i:C = RU, O = The Ministry of Digital Development and Communications, CN = Russian Trusted Sub CA ... --- Server certificate subject=C = RU, ST = Moscow, L = Moscow, O = Sberbank of Russia PJSC, CN = ngw.devices.sberbank.ru issuer=C = RU, O = The Ministry of Digital Development and Communications, CN = Russian Trusted Sub CA --- Acceptable client certificate CA names C = RU, O = Sberbank of Russia, CN = SberCA Ext C = RU, O = Sberbank of Russia, CN = SberCA Root Ext Client Certificate Types: RSA sign, DSA sign, ECDSA sign Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1 Shared Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224 Peer signing digest: SHA512 Peer signature type: RSA Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 6077 bytes and written 453 bytes Verification error: self signed certificate in certificate chain --- New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES128-GCM-SHA256 Session-ID: 123D6B99846A9C48A7A9164C95D615F8D2347E4B11CACB055141038B0C1D58E8 Session-ID-ctx: Master-Key: 6A83099F76AACCE7438015EFECA6B6B68E01F73ACA620262089CAE7102D991C3EECF6958EF16DA04A0ACD04C39E9A9B9 PSK identity: None PSK identity hint: None SRP username: None Start Time: 1699119436 Timeout : 7200 (sec) Verify return code: 19 (self signed certificate in certificate chain) Extended master secret: no --- Verify return code: 19 (self signed certificate in certificate chain) - кажется, это их косяк. Но ошибки это не умаляет. Буду стучаться к ним в техподдержку
Это не то чтобы их косяк. Просто корневого СА рф сертов нет в системе
Вы правы, но данная проблема (пока что при локальной разработке) успешно обходится кодом из этого сообщения. ОК. Но теперь мне Axios в виде ошибки (опять же в том же сообщении по ссылке) просто выплевывает реквест. Судя по всему, запрос даже не отсылается на сервер, и просто выплевывается его тело как ошибка - это мне подсказал ChatGPT потому что я в отчаянии. Почему так? Может, я переигрался с интерцепторами? ОК, я упростил код, кинул весь код в один поток, но поведение осталось то же. А я ведь просто хотел запилить бота-автоответчика в ватсаппе и телеге... почему всё так сложно...
Решил проблему. Как всегда, виноват я сам. Я в интерцепторе написал, что если url не соответствует шаблону, то вали все запросы, которые перехватит. Вот он и валил запрос авторизации, соответственно и JWT-токен 5-минутный не вшивался в последующие запросы, и те тоже валились, потому что не расово правильные, не по шаблону пацанчики были. Одну строчку убрал, и всё заработало, кек.
Обсуждают сегодня