Ошибка 400 ssl certificate error

First of all, enable debug log in nginx.conf:

error_log  logs/error.log debug;

And restart nginx. Then repeat the request and check the log file. Find the first line with verify:0:

2019/12/05 22:34:50 [debug] 5980#9776: *17 verify:0, error:20, depth:0, subject:"/CN=...", issuer:"/CN=..."

Here you see error:20. The error code comes from OpenSSL. Here you can find the constant name by code and here the corresponding description by constant name.

Alternatively you can verify the certificate using openssl command line tool:

openssl verify -CAfile ca.crt client.crt

To verify it as the server sees it, ca.crt has to be the file listed in ssl_client_certificate or ssl_trusted_certificate directive in nginx.conf.

To verify the certificate on its own, ca.crt has to be the certificate that was used to sign client.crt. If it is self-signed, it’ll be client.crt itself (client.crt will be twice in a row).

If you’re getting error 20 specifically and your client certificate is self-signed, you might have encountered this bug. To fix it you should either drop keyUsage from your certificate entirely or add keyCertSign to the list. To verify whether you’ve stumbled upon it, check whether Key Usage is listed in X509v3 extensions: section in the output of the following command:

openssl x509 -in client.crt -text -noout

Источник

I am trying to configure two-way SSL with SSL certs (for server and client) signed by Intermediate CAs. This is what I have done so far following this tutorial.

Server — nginx application

Nginx is configured with SSL certificate (signed by an Intermediate CA).

server {
  listen 443;
  server_name app-ca.test.com;
  ssl on;

  ssl_certificate /root/ca/intermediate/certs/app-plus-intermediate.pem;
  ssl_certificate_key /root/ca/intermediate/private/app-ca-interm-ca.test.com.key.pem;
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers  HIGH:!aNULL:!MD5;
  ssl_prefer_server_ciphers   on;

  # I have also tried adding the Intermediate CA cert in vain
  # ssl_client_certificate /root/client_rootca_intermediate.crt;
  ssl_client_certificate /root/client_rootca.crt;
  ssl_verify_client on;

  location / {
      root /usr/share/nginx/massl;
      index index.html index.htm;
  }
}

Client — curl or OpenSSL s_client

I have a client certificate signed by some other Intermediate CA, which fails with 400 The SSL certificate error

I have also tried to pass (-cert option in openssl command) Client’s Intermediate CA and Root CA along with the client certificate in vain.

$ cat /root/ca/intermediate/certs/client.cert.pem /root/ca/intermediate/certs/intermediate.cert.pem > /root/ca/intermediate/certs/client_plus_intermediate.cert.pem

$ cat /root/ca/intermediate/certs/client.cert.pem /root/ca/intermediate/certs/intermediate.cert.pem > /root/ca/intermediate/certs/intermediate_plus_client.cert.pem

$ cat /root/ca/intermediate/certs/client.cert.pem /root/ca/intermediate/certs/intermediate.cert.pem /root/ca/certs/ca.cert.pem > /root/ca/intermediate/certs/client_plus_intermediate_plus_ca.cert.pem

Short Error Logs

<html>
<head><title>400 The SSL certificate error</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<center>The SSL certificate error</center>
<hr><center>nginx/1.13.5</center>
</body>
</html>

Long Error Logs

I have shortened the longs hashes for brevity.

$ openssl s_client -connect app-ca.test.com:443 -tls1 -key /root/ca/intermediate/private/client.key.pem -cert /root/ca/intermediate/certs/client.cert.pem -CAfile /root/server_rootca.crt -state -debug
CONNECTED(00000003)
SSL_connect:before/connect initialization
write to 0x2239a90 [0x226e3c3] (181 bytes => 181 (0xB5))
0000 - 16 03 01 00 b0 01 00 00-ac 03 01 16 ed fa 81 3e   ...............>
0010 - fc 25 c1 55 73 8a ca 5f-d3 56 11 a6 0f 38 6e 3c   .%.Us.._.V...8n<
0020 - 52 fb 1f 9b fb 4f 4f 3e-5a fb 82 00 00 64 c0 14   R....OO>Z....d..
0090 - 00 ff 01 00 00 1f 00 0b-00 04 03 00 01 02 00 0a   ................
00a0 - 00 0a 00 08 00 17 00 19-00 18 00 16 00 23 00 00   .............#..
00b0 - 00 0f 00 01 01                                    .....
SSL_connect:SSLv3 write client hello A
read from 0x2239a90 [0x2269e73] (5 bytes => 5 (0x5))
0000 - 16 03 01 00 42                                    ....B
read from 0x2239a90 [0x2269e78] (66 bytes => 66 (0x42))
0000 - 02 00 00 3e 03 01 6f e5-89 1d bd 5a 58 26 d7 11   ...>..o....ZX&..
0010 - 8a 05 fd 2a 04 96 58 2e-2e 19 a7 89 46 a0 5b 21   ...*..X.....F.[!
0020 - c3 90 1c 3e 0b e6 00 c0-14 00 00 16 ff 01 00 01   ...>............
0030 - 00 00 0b 00 04 03 00 01-02 00 23 00 00 00 0f 00   ..........#.....
0040 - 01 01                                             ..
SSL_connect:SSLv3 read server hello A
read from 0x2239a90 [0x2269e73] (5 bytes => 5 (0x5))
0000 - 16 03 01 0c ab                                    .....
read from 0x2239a90 [0x2269e78] (3243 bytes => 3243 (0xCAB))
0000 - 0b 00 0c a7 00 0c a4 00-06 64 30 82 06 60 30 82   .........d0..`0.

0c90 - 5f b6 c7 86 5d 41 b3 fb-9c fe d3 0a 26 01 f9 d9   _...]A......&...
0ca0 - a6 ae 7f ff 4f c7 0b e8-97 b3 1c                  ....O......
depth=2 C = GB, ST = England, L = Melbourne, O = Alice Ltd, OU = IT Services, CN = server-and-ca.test.com, emailAddress = root@server-and-ca.test.com
verify return:1
depth=1 C = GB, ST = England, O = Alice Ltd, OU = Shared Services, CN = server-and-interm-ca.test.com, emailAddress = root@server-and-interm-ca.test.com
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Alice Ltd, OU = Alice Ltd Web Services, CN = app-ca-interm-ca.test.com, emailAddress = root@app-ca-interm-ca.test.com
verify return:1
SSL_connect:SSLv3 read server certificate A
read from 0x2239a90 [0x2269e73] (5 bytes => 5 (0x5))
0000 - 16 03 01 01 4b                                    ....K
read from 0x2239a90 [0x2269e78] (331 bytes => 331 (0x14B))
0000 - 0c 00 01 47 03 00 17 41-04 13 5d 81 04 36 18 e7   ...G...A..]..6..
0010 - da bf 5e 30 dd d8 ee 77-f9 56 aa 77 8b 9e cd 3e   ..^0...w.V.w...>.
0110 - d1 82 65 0f 5d 9c 03 ba-5f 7f 62 33 a8 a6 62 8e   ..e.]..._.b3..b.
0120 - f2 5c 03 1d 4d 47 04 16-cb 80 09 39 32 be ca 23   ...MG.....92..#
0130 - 41 95 36 a6 4b 6b f0 6c-df a5 4b 26 d4 4a c5 f3   A.6.Kk.l..K&.J..
0140 - 99 0d c8 d8 aa 5d f8 88-86 b3 15                  .....].....
SSL_connect:SSLv3 read server key exchange A
read from 0x2239a90 [0x2269e73] (5 bytes => 5 (0x5))
0000 - 16 03 01 00 bc                                    .....
read from 0x2239a90 [0x2269e78] (188 bytes => 188 (0xBC))
0000 - 0d 00 00 b4 03 01 02 40-00 ae 00 ac 30 81 a9 31   .......@....0..1
0010 - 0b 30 09 06 03 55 04 06-13 02 47 42 31 10 30 0e   .0...U....GB1.0.
0090 - 06 09 2a 86 48 86 f7 0d-01 09 01 16 1b 72 6f 6f   ..*.H........roo
00a0 - 74 40 63 6c 69 65 6e 74-2d 61 6e 64 2d 63 61 2e   t@client-and-ca.
00b0 - 74 65 73 74 2e 63 6f 6d-0e                        test.com.
00bc - <SPACES/NULS>
SSL_connect:SSLv3 read server certificate request A
SSL_connect:SSLv3 read server done A
write to 0x2239a90 [0x2273910] (1593 bytes => 1593 (0x639))
0000 - 16 03 01 06 34 0b 00 06-30 00 06 2d 00 06 2a 30   ....4...0..-..*0
0010 - 82 06 26 30 82 04 0e a0-03 02 01 02 02 02 10 00   ..&0............
05f0 - 29 2a 6c 40 d1 ed 8f 6d-15 b2 cd 6a 7b 72 30 91   )*l@...m...j{r0.
0600 - ea 29 16 48 f2 11 21 15-3a 50 32 8b 95 87 b8 09   .).H..!.:P2.....
0610 - 11 84 9a a4 d2 b8 46 33-7a a2 79 51 ba 23 8c 96   ......F3z.yQ.#..
0620 - 45 62 2e b9 f5 ea 23 79-53 e0 cb 72 1f e6 19 d4   Eb....#yS..r....
0630 - 75 18 a8 2e 44 2f f3 8b-a7                        u...D/...
SSL_connect:SSLv3 write client certificate A
write to 0x2239a90 [0x2273910] (75 bytes => 75 (0x4B))
0000 - 16 03 01 00 46 10 00 00-42 41 04 b9 b3 02 d2 bc   ....F...BA......
0010 - e2 8b 49 a7 f6 8c 59 66-fc 0e 39 79 c7 23 34 e9   ..I...Yf..9y.#4.
0020 - 3e 04 98 3a 60 78 1d aa-51 06 46 80 09 10 c4 7e   >..:`x..Q.F....~
0030 - a5 e7 05 d1 82 f2 0d bb-9a ca e7 29 01 0b 88 6d   ...........)...m
0040 - ed c3 52 73 b1 d4 3a 95-00 e8                     ..Rs..:...
004b - <SPACES/NULS>
SSL_connect:SSLv3 write client key exchange A
write to 0x2239a90 [0x2273910] (267 bytes => 267 (0x10B))
0000 - 16 03 01 01 06 0f 00 01-02 01 00 5e 29 8e 7c 69   ...........^).|i
0010 - 1e 10 0d 01 39 35 db 18-7e 4a a7 12 ae 12 7e f0   ....95..~J....~.
0020 - d6 93 c5 0a ba 5d e4 f1-a4 ae 8f c4 7d 52 80 16   .....]......}R..
00f0 - 6f 1f 56 73 bc ab 7f 07-1d f7 b4 ec d7 58 57 cd   o.Vs.........XW.
0100 - cd e0 37 b3 58 09 3a 75-93 02 ab                  ..7.X.:u...
SSL_connect:SSLv3 write certificate verify A
write to 0x2239a90 [0x2273910] (6 bytes => 6 (0x6))
0000 - 14 03 01 00 01 01                                 ......
SSL_connect:SSLv3 write change cipher spec A
write to 0x2239a90 [0x2273910] (53 bytes => 53 (0x35))
0000 - 16 03 01 00 30 24 90 78-08 d3 10 f3 f8 e3 c8 86   ....0$.x........
0010 - 82 f1 54 d1 38 7b 57 7b-83 a3 49 b9 3b 80 b2 86   ..T.8{W{..I.;...
0020 - 54 74 92 ec 9a a7 e7 28-1a ec 72 4c 64 8e f3 e3   Tt.....(..rLd...
0030 - 08 96 89 2a 03                                    ...*.
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
read from 0x2239a90 [0x2269e73] (5 bytes => 5 (0x5))
0000 - 16 03 01 06 ea                                    .....
read from 0x2239a90 [0x2269e78] (1770 bytes => 1770 (0x6EA))
0000 - 04 00 06 e6 00 00 01 2c-06 e0 09 8d 58 07 45 c9   .......,....X.E.
0010 - 58 49 42 f4 13 00 47 12-be 22 a2 e3 a0 b6 22 bd   XIB...G.."....".
06d0 - a1 11 26 db 43 c8 6e 47-2f 40 65 61 e1 4e ef 0a   ..&.C.nG/@ea.N..
06e0 - 57 e0 28 19 2d 0d c6 7f-ae 2e                     W.(.-.....
SSL_connect:SSLv3 read server session ticket A
read from 0x2239a90 [0x2269e73] (5 bytes => 5 (0x5))
0000 - 14 03 01 00 01                                    .....
read from 0x2239a90 [0x2269e78] (1 bytes => 1 (0x1))
0000 - 01                                                .
read from 0x2239a90 [0x2269e73] (5 bytes => 5 (0x5))
0000 - 16 03 01 00 30                                    ....0
read from 0x2239a90 [0x2269e78] (48 bytes => 48 (0x30))
0000 - 7d 5f 53 a4 5e 85 67 67-8d 6c d6 6e 93 cd c6 75   }_S.^.gg.l.n...u
0010 - c1 83 17 d9 a8 e3 89 23-86 6b 8a 04 2d 46 7e 95   .......#.k..-F~.
0020 - 15 46 a4 ec 73 f3 3d 78-1b 0e 94 62 79 cf 96 3d   .F..s.=x...by..=
SSL_connect:SSLv3 read finished A
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Alice Ltd/OU=Alice Ltd Web Services/CN=app-ca-interm-ca.test.com/emailAddress=root@app-ca-interm-ca.test.com
   i:/C=GB/ST=England/O=Alice Ltd/OU=Shared Services/CN=server-and-interm-ca.test.com/emailAddress=root@server-and-interm-ca.test.com
 1 s:/C=GB/ST=England/O=Alice Ltd/OU=Shared Services/CN=server-and-interm-ca.test.com/emailAddress=root@server-and-interm-ca.test.com
   i:/C=GB/ST=England/L=Melbourne/O=Alice Ltd/OU=IT Services/CN=server-and-ca.test.com/emailAddress=root@server-and-ca.test.com
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGYDCCBEigAwIBAgICEAAwDQYJKoZIhvcNAQELBQAwgagxCzAJBgNVBAYTAkdC
MRAwDgYDVQQIDAdFbmdsYW5kMRIwEAYDVQQKDAlBbGljZSBMdGQxGDAWBgNVBAsM
zBcik+fj+MUtDzhEl6EuW1ILjAvt5u4KBxj6d0yAXzleACOYncYWWzMfQdrFmwKh
W2opZQ==
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Alice Ltd/OU=Alice Ltd Web Services/CN=app-ca-interm-ca.test.com/emailAddress=root@app-ca-interm-ca.test.com
issuer=/C=GB/ST=England/O=Alice Ltd/OU=Shared Services/CN=server-and-interm-ca.test.com/emailAddress=root@server-and-interm-ca.test.com
---
Acceptable client certificate CA names
/C=GB/ST=England/L=Sydney/O=Something/OU=Shared Services/CN=client-and-ca.test.com/emailAddress=root@client-and-ca.test.com
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 5682 bytes and written 2175 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : ECDHE-RSA-AES256-SHA
    Session-ID: 2AF7BFD60D3EC4686EAAAE1971FBD8999E65C5C80A32182CB9A668B1411DB09C
    Session-ID-ctx:
    Master-Key: B3F714B4ACB61C6310311025B25AFBAFA9E9AAEBB5ACD5FEEAE5DCAE2690DECBFA4EC5CBD2C8A50F349F43026CD0C564
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 09 8d 58 07 45 c9 58 49-42 f4 13 00 47 12 be 22   ..X.E.XIB...G.."
    0010 - a2 e3 a0 b6 22 bd 0d 71-c9 46 bd ab 84 85 06 f7   ...."..q.F......
    06b0 - 66 76 1f 3e 49 23 dc 2b-be 9e d5 03 b8 a5 a1 7d   fv.>I#.+.......}
    06c0 - 4d 56 79 3f 81 78 a1 11-26 db 43 c8 6e 47 2f 40   MVy?.x..&.C.nG/@
    06d0 - 65 61 e1 4e ef 0a 57 e0-28 19 2d 0d c6 7f ae 2e   ea.N..W.(.-.....

    Start Time: 1506251677
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---
GET / HTTP/1.0
write to 0x2239a90 [0x226e3c6] (90 bytes => 90 (0x5A))
0000 - 17 03 01 00 20 ca 44 95-8c a0 32 52 4d da d8 02   .... .D...2RM...
0010 - db bd 97 88 0e e3 cb b9-9e fb 50 7e 71 24 37 83   ..........P~q$7.
0020 - f8 48 03 a0 a1 17 03 01-00 30 db 99 b2 0c 6c e6   .H.......0....l.
0030 - f4 25 3d 54 2f b1 a3 3c-be 2a 36 94 6c ce 6d 8d   .%=T/..<.*6.l.m.
0040 - 3d 54 82 d3 f0 2a 40 3d-fc 3f 1b 3e 4a 40 10 e5   =T...*@=.?.>J@..
0050 - 1d eb ab 00 69 f1 e0 4a-27 47                     ....i..J'G

write to 0x2239a90 [0x226e3c6] (74 bytes => 74 (0x4A))
0000 - 17 03 01 00 20 95 06 3d-51 d5 7c c2 05 ef a7 d6   .... ..=Q.|.....
0010 - 2b 25 9c dd ec 5f 7c c0-15 83 c6 ca ea 47 a1 b2   +%..._|......G..
0020 - 82 2d 46 7d 64 17 03 01-00 20 3b 2e 36 63 10 b3   .-F}d.... ;.6c..
0030 - 50 c7 ec 36 a4 27 a0 4d-db bb 83 b5 c6 e8 d5 fa   P..6.'.M........
0040 - ca 76 dc e7 63 8f 94 b3-24 3f                     .v..c...$?
read from 0x2239a90 [0x2269e73] (5 bytes => 5 (0x5))
0000 - 17 03 01 01 a0                                    .....
read from 0x2239a90 [0x2269e78] (416 bytes => 416 (0x1A0))
0000 - a6 8b c1 bb a4 aa 12 2e-81 d9 45 41 74 0e 33 a4   ..........EAt.3.
0190 - 37 be 58 ca 01 80 fc 7c-79 2b 3f 54 a4 cd 4a 07   7.X....|y+?T..J.
HTTP/1.1 400 Bad Request
Server: nginx/1.13.5
Date: Sun, 24 Sep 2017 11:14:49 GMT
Content-Type: text/html
Content-Length: 231
Connection: close

<html>
<head><title>400 The SSL certificate error</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<center>The SSL certificate error</center>
<hr><center>nginx/1.13.5</center>
</body>
</html>
read from 0x2239a90 [0x2269e73] (5 bytes => 5 (0x5))
0000 - 15 03 01                                          ...
0005 - <SPACES/NULS>
read from 0x2239a90 [0x2269e78] (32 bytes => 32 (0x20))
0000 - c3 75 ba 40 21 83 f7 0e-11 98 7b 44 84 bb 23 d5   .u.@!.....{D..#.
0010 - 80 32 1e 3e b6 b7 dd 4a-16 09 31 e9 62 a9 cd a3   .2.>...J..1.b...
SSL3 alert read:warning:close notify
closed
write to 0x2239a90 [0x226e3c3] (37 bytes => 37 (0x25))
0000 - 15 03 01 00 20 bd 18 f2-df 1b 84 fc 8e e0 80 a1   .... ...........
0010 - 2f 6f 31 b4 4c fc 1c e5-36 1f c5 fb 5d c0 f8 dc   /o1.L...6...]...
0020 - 19 6b 03 c3 2d                                    .k..-
SSL3 alert write:warning:close notify

Interestingly, the above command works fine if I use certificates of Client’s Root CA or Client’s Intermediate CA.

Источник


0

2

nginx 1.6.2, самоподписанные сертификаты сервера и клиента, openssl проверку проходят:

$ openssl verify -CAfile server/server.crt client01.crt 
client01.crt: C = RU, ST = Moscow, L = Moscow, O = Companyname, OU = User, CN = etc, emailAddress = support@site.com
error 18 at 0 depth lookup:self signed certificate
OK

А при запросе nginx отвечает ошибкой 400 The SSL certificate error

В логах сервера: 

2016/04/22 11:16:20 [info] 1465#0: *35 client SSL certificate verify error: (18:self signed certificate) wh
ile reading client request headers, client: 192.168.2.11, server: _, request: "GET /test HTTP/1.1", host: "
192.168.2.6"                                                                                               
2016/04/22 11:16:20 [debug] 1465#0: *35 http finalize request: 495, "/test?" a:1, c:1                      
2016/04/22 11:16:20 [debug] 1465#0: *35 event timer del: 8: 1461313040230                                  
2016/04/22 11:16:20 [debug] 1465#0: *35 http special response: 495, "/test?"                               
2016/04/22 11:16:20 [debug] 1465#0: *35 http set discard body                                              
2016/04/22 11:16:20 [debug] 1465#0: *35 echo header filter, uri "/test?"                                   
2016/04/22 11:16:20 [debug] 1465#0: *35 xslt filter header                                                 
2016/04/22 11:16:20 [debug] 1465#0: *35 posix_memalign: 0000000001F02580:4096 @16                          
2016/04/22 11:16:20 [debug] 1465#0: *35 HTTP/1.1 400 Bad Request

Настройки nginx: 

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    ssl on;
    ssl_certificate /etc/nginx/ssl/server.crt;
    ssl_certificate_key /etc/nginx/ssl/server.nopass.key;
    ssl_client_certificate /etc/nginx/ssl/ca.crt;
    ssl_verify_client on;

    location {
        proxy_pass  http://192.168.2.6:9080;
    }
}

Я правильно понимаю, что серверу не нравится то, что сертификат самоподписанный? Как разрешить?

Источник

Ошибка 400 Bad Request возникает, когда сервер не может понять запрос, отправленный клиентом. В вашем случае это может быть связано с тем, что настройки сервера не соответствуют запросу.

Судя по коду из вашего nginx.conf, вы пытаетесь перенаправить HTTP-запросы на HTTPS-порт с помощью rewrite. Однако вместо этого запросы на порт 8080 проксируются на другой сервер.

Для исправления проблемы с ошибкой 400 вам нужно изменить ваш nginx.conf, чтобы он правильно перенаправлял HTTP-запросы на HTTPS-порт.

Примерно так должно выглядеть ваш nginx.conf:

server {
    listen 80;
    server_name example.com;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/cert.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    location / {
        root /var/www/example.com/;
        index index.html;
    }

    location /server/ {
        resolver 00.000.000.00;
        proxy_pass https://00.000.000.00;
    }
}

Этот конфигурационный файл перенаправляет все запросы на порт 80 (HTTP) на порт 443 (HTTPS) с помощью return 301. Затем он обрабатывает запросы на порт 443 (HTTPS), предоставляя файлы из каталога /var/www/example.com/ для пути / и проксируя запросы на путь /server/ на другой сервер.

Убедитесь, что после внесения изменений вы перезапустили сервер NGINX с помощью команды
sudo systemctl restart nginx.

Источник
 

 Loading…

Skip to page content
Skip to page content

Источник

Offline

vdchernikov

 


#1
Оставлено
:
16 ноября 2020 г. 13:35:41(UTC)

vdchernikov

Статус: Активный участник

Группы: Участники

Зарегистрирован: 17.10.2019(UTC)
Сообщений: 28
Российская Федерация
Откуда: Ярославская обл.

Сказал(а) «Спасибо»: 1 раз

Добрый день!
Используем КриптоПРО на iOS/Android в мобильном приложении для шифрования трафика с Stunnel.

сервер ContinentTLS с недавних пор после генерации новых сертифкатов федеральным казначеством
стал возвращать ошибку 400 Bad request Ssl certificate error.

На Android ошибку удалось испарвить путем включения всей цепочки сертифкатов в контейнер пользователя
(тема https://www.cryptopro.ru…osts&t=18835&p=1 )

Но тотже самы контейнер пользователя со всей цепочкой сертифкатов не оказывает эффекта на iOS версии.
Есть подозрение что КриптоПРО на iOS просто не отправляет доплнительные сертифкаты на сервер и игнорирует сертифкаты вложенные в контейнер;

И второй вопрос можно ли както на iOS также как на Android посмотреть в логах какие сертификаты отсылаются на сервер, аналогично логам Android:

Цитата:

%% Certificate message:

Subject: CN=Фамилия Имя Отчество, SURNAME=Фамилия, GIVENNAME=Имя Отчество, O=ФЕДЕРАЛЬНОЕ КАЗНАЧЕЙСТВО, L=Москва, ST=г. Москва, C=RU, EMAILADDRESS=address@roskazna.ru, OID.1.2.643.100.3=#120B3035333635303137313339, OID.1.2.643.3.131.1.1=#120C343032353031313533383435
Valid from Wed Sep 09 16:44:00 GMT+03:00 2020 until Thu Dec 09 16:44:00 GMT+03:00 2021

Subject: CN=Федеральное казначейство, O=Федеральное казначейство, C=RU, L=Москва, STREET=»Большой Златоустинский переулок, д. 6, строение 1″, OID.1.2.643.100.1=#120D31303437373937303139383330, OID.1.2.643.3.131.1.1=#120C303037373130353638373630, ST=г. Москва, EMAILADDRESS=uc_fk@roskazna.ru
Valid from Wed Feb 05 17:02:47 GMT+03:00 2020 until Mon Feb 05 17:02:47 GMT+03:00 2035

Subject: CN=Минкомсвязь России, OID.1.2.643.3.131.1.1=#120C303037373130343734333735, OID.1.2.643.100.1=#120D31303437373032303236373031, O=Минкомсвязь России, STREET=»улица Тверская, дом 7″, L=г. Москва, ST=77 Москва, C=RU, EMAILADDRESS=dit@minsvyaz.ru
Valid from Fri Jul 06 15:18:06 GMT+03:00 2018 until Tue Jul 01 15:18:06 GMT+03:00 2036
——

Отредактировано пользователем 16 ноября 2020 г. 14:15:04(UTC)
 | Причина: Не указана

Вверх

Offline

Александр Лавник

 


#2
Оставлено
:
22 ноября 2020 г. 21:48:46(UTC)

Александр Лавник

Статус: Сотрудник

Группы: Участники

Зарегистрирован: 30.06.2016(UTC)
Сообщений: 3,304
Мужчина
Российская Федерация

Сказал «Спасибо»: 53 раз
Поблагодарили: 746 раз в 694 постах

Здравствуйте.

Если вопрос еще актуален, то попробуйте установить сертификаты промежуточных УЦ для сертификата клиента и сервера в хранилище ca (Промежуточные центры сертификации) и проверить работу.

Техническую поддержку оказываем тут
Наша база знаний

Вверх
Пользователи, просматривающие эту тему

Guest

Быстрый переход
 

Вы не можете создавать новые темы в этом форуме.

Вы не можете отвечать в этом форуме.

Вы не можете удалять Ваши сообщения в этом форуме.

Вы не можете редактировать Ваши сообщения в этом форуме.

Вы не можете создавать опросы в этом форуме.

Вы не можете голосовать в этом форуме.

Источник

Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see https://kubernetes.io/docs/tasks/debug-application-cluster/troubleshooting/.):

What keywords did you search in NGINX Ingress controller issues before filing this one? (If you have found any duplicates, you should instead reply there.):
400 The SSL certificate error

Is this a BUG REPORT or FEATURE REQUEST? (choose one):
BUG REPORT

NGINX Ingress controller version:
0.26.1

Kubernetes version (use kubectl version):
v1.13.0

Environment:

  • Cloud provider or hardware configuration: baremetal
  • OS (e.g. from /etc/os-release):Linux
  • Kernel (e.g. uname -a):4.4.0-157-generic
  • Install tools:Helm
  • Others:

What happened:
when i am trying to access my service (using ingress path e.g. curl -v https://172.16.141.196:31345/test1 —cert client.crt —key client.key —cacert ca.crt) using certificate it through an error «400 The SSL certificate error» related to certificate.

Ingress resource Configuration:
root@master196:~# kubectl get ing
NAME HOSTS ADDRESS PORTS AGE
altran-nginx-ingress * 80 3d23h

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/auth-tls-secret: default/ssl-nginx-certs
nginx.ingress.kubernetes.io/auth-tls-verify-client: «on»
nginx.ingress.kubernetes.io/ssl-redirect: «false»
creationTimestamp: «2019-10-10T20:37:28Z»
generation: 1
name: altran-nginx-ingress
namespace: default
resourceVersion: «501479»
selfLink: /apis/extensions/v1beta1/namespaces/default/ingresses/altran-nginx-ingress
uid: c688bb5d-eb9d-11e9-82cc-fa163e81c42f
spec:
rules:

  • http:
    paths:

    • backend:
      serviceName: service-custom
      servicePort: 5685
      path: /test1
      status:
      loadBalancer:
      ingress:
    • {}

NGINX Ingress Controller Logs:

NGINX Ingress controller
Release: 0.26.1
Build: git-2de5a893a
Repository: https://github.com/kubernetes/ingress-nginx
I1011 18:49:44.675153 6 flags.go:198] Watching for Ingress class: nginx
nginx version: openresty/1.15.8.2

W1011 18:49:44.676436 6 flags.go:243] SSL certificate chain completion is disabled (—enable-ssl-chain-completion=false)
W1011 18:49:44.676507 6 client_config.go:541] Neither —kubeconfig nor —master was specified. Using the inClusterConfig. This might not work.
I1011 18:49:44.676777 6 main.go:182] Creating API client for https://10.241.0.1:443
I1011 18:49:45.694577 6 main.go:226] Running in Kubernetes cluster version v1.13 (v1.13.0) — git (clean) commit ddf47ac13c1a9483ea035a79cd7c10005ff21a6d — platform linux/amd64
I1011 18:49:45.699556 6 main.go:90] Validated default/my-nginx-nginx-ingress-default-backend as the default backend.
I1011 18:49:46.965276 6 main.go:101] SSL fake certificate created /etc/ingress-controller/ssl/default-fake-certificate.pem
W1011 18:49:46.969205 6 main.go:105] Using deprecated «k8s.io/api/extensions/v1beta1» package because Kubernetes version is < v1.14.0
W1011 18:49:47.023719 6 store.go:635] Unexpected error reading configuration configmap: configmaps «my-nginx-nginx-ingress-controller» not found
I1011 18:49:47.042456 6 nginx.go:263] Starting NGINX Ingress controller
I1011 18:49:47.091925 6 event.go:255] Event(v1.ObjectReference{Kind:»ConfigMap», Namespace:»default», Name:»udp-controller-configmap», UID:»84c936f8-eb8b-11e9-82cc-fa163e81c42f», APIVersion:»v1″, ResourceVersion:»5170″, FieldPath:»»}): type: ‘Normal’ reason: ‘CREATE’ ConfigMap default/udp-controller-configmap
I1011 18:49:47.092164 6 event.go:255] Event(v1.ObjectReference{Kind:»ConfigMap», Namespace:»default», Name:»tcp-controller-configmap», UID:»84c6e582-eb8b-11e9-82cc-fa163e81c42f», APIVersion:»v1″, ResourceVersion:»5169″, FieldPath:»»}): type: ‘Normal’ reason: ‘CREATE’ ConfigMap default/tcp-controller-configmap
I1011 18:49:47.092436 6 backend_ssl.go:66] Adding Secret «default/my-certs» to the local store
I1011 18:49:48.154294 6 backend_ssl.go:66] Adding Secret «default/ssl-nginx-certs» to the local store
I1011 18:49:48.155563 6 event.go:255] Event(v1.ObjectReference{Kind:»Ingress», Namespace:»default», Name:»altran-nginx-ingress», UID:»c688bb5d-eb9d-11e9-82cc-fa163e81c42f», APIVersion:»networking.k8s.io/v1beta1″, ResourceVersion:»16659″, FieldPath:»»}): type: ‘Normal’ reason: ‘CREATE’ Ingress default/altran-nginx-ingress
I1011 18:49:48.244452 6 nginx.go:307] Starting NGINX process
I1011 18:49:48.244575 6 leaderelection.go:241] attempting to acquire leader lease default/ingress-controller-leader-nginx…
W1011 18:49:48.245778 6 controller.go:316] Error getting Service «default/dummy-service»: no object matching key «default/dummy-service» in local store
W1011 18:49:48.245819 6 controller.go:316] Error getting Service «default/dummy-service»: no object matching key «default/dummy-service» in local store
I1011 18:49:48.245841 6 controller.go:134] Configuration changes detected, backend reload required.
I1011 18:49:48.2

What you expected to happen:
when i access my service with correct client certificate it should be accessed as with port 80 , it is being accessed.

How to reproduce it (as minimally and precisely as possible):
Installed NGINX first through Helm
create secret using ca certificate

Anything else we need to know:
With nginx image 0.25, it is working fine.
I use nginx image 0.25.1 it has some other configuration in nginx.conf file. here service port mentioned and certificate location is in within the server
here is the code of nginx.conf with 0.25.1 image
## start server _
server {
server_name _ ;

	listen 80 default_server reuseport backlog=511 ;
	listen 443 default_server reuseport backlog=511 ssl http2 ;
	
	set $proxy_upstream_name "-";
	
	# PEM sha: ee83f25d148379e2aa68349a542c2eea275fa1e0
	ssl_certificate                         /etc/ingress-controller/ssl/default-fake-certificate.pem;
	ssl_certificate_key                     /etc/ingress-controller/ssl/default-fake-certificate.pem;
	
	ssl_certificate_by_lua_block {
		certificate.call()
	}
	
	# PEM sha: ee83f25d148379e2aa68349a542c2eea275fa1e0
	ssl_client_certificate                  /etc/ingress-controller/ssl/default-my-certs.pem;
	ssl_verify_client                       on;
	ssl_verify_depth                        1;
	
	location /test1 {
		
		set $namespace      "default";
		set $ingress_name   "altran-nginx-ingress";
		set $service_name   "";
	set $service_port   "{0 5685 }";
		set $location_path  "/test1";

when I use nginx image 0.26.1 it has some diffrent configuration. in this version service port is missing and certificate location is changed.
here is code:
## start server _
server {
server_name _ ;

	listen 80 default_server reuseport backlog=511 ;
	listen 443 default_server reuseport backlog=511 ssl http2 ;
	
	set $proxy_upstream_name "-";
	
	# PEM sha: ee83f25d148379e2aa68349a542c2eea275fa1e0
	ssl_certificate                         /etc/ingress-controller/ssl/default-fake-certificate.pem;
	ssl_certificate_key                     /etc/ingress-controller/ssl/default-fake-certificate.pem;
	
	ssl_certificate_by_lua_block {
		certificate.call()
	}
	
	# PEM sha: ee83f25d148379e2aa68349a542c2eea275fa1e0
	ssl_client_certificate                  /etc/ingress-controller/ssl/default-my-certs.pem;
	ssl_verify_client                       on;
	ssl_verify_depth                        1;
	
	location /test1 {
		
		set $namespace      "default";
		set $ingress_name   "altran-nginx-ingress";
		set $service_name   "";
	set $service_port   "{0 5685 }";
		set $location_path  "/test1";

when i use 0.25.1 nginx image i can access my service and when i use 0.26.1 nginx image i can not access the service.

please let me know in case of any other information is required.

Thanks in advance.

Regards,
Kuldeep

Источник

Answer by Hendrix Morris

The HyperText Transfer Protocol (HTTP) 400 Bad Request response status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).,HTTP response status codes,Warning: The client should not repeat this request without modification.,

HTTP guide

Basics of HTTP
Overview of HTTP
Evolution of HTTP
HTTP Messages
A typical HTTP session
Connection management in HTTP/1.x
Protocol upgrade mechanism

400 Bad Request

Answer by Averi Duncan

Also, enclose your data as JSON in the request body, don’t pass them as URL parameters. You are passing JSON data in your curl example as well.,and corresponding curl request is ,Please be sure to answer the question. Provide details and share your research!,Making statements based on opinion; back them up with references or personal experience.

Also, enclose your data as JSON in the request body, don’t pass them as URL parameters. You are passing JSON data in your curl example as well.

import requests


data = {
    "externalId": "801411",
    "name": "RD Core",
    "description": "Tenant create",
    "subscriptionType": "MINIMAL",
    "features": {
        "capture": False,
        "correspondence": True,
        "vault": False
    }
}

response = requests.post(
    url="http://localhost:9100/tenants/",
    json=data
)

print response.status_code, response.reason

Answer by Melani Patrick

The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).,The key concept to understand here is that the 400 Bad Request error is something that has to do with the submitted request from the client before it is even processed by the server.,The 400 Bad Request Error is an HTTP response status code
that indicates the server was unable to process (understand) the request sent by the client due to incorrect syntax, invalid request message framing, or deceptive request routing.,The 4xx family of status codes is the one we’re investigating here as they relate to invalid or corrupt requests from the client. Specifically, we’ll take a closer look at the 400 Bad Request error: what this error means, what causes it as well as some specific steps to fix the issue.

This is surprisingly easy to do by mistake and can happen if a URL has been encoding incorrectly. The following link is an example of a URL containing characters the server won’t be able to process, hence a 400 Bad Request error is triggered.

https://twitter.com/share?lang=en&text=Example%20of%20malformed%%20characters%20in%20URL

https://twitter.com/share?lang=en&text=Example%20of%20malformed%%20characters%20in%20URL

Answer by Dexter English

I received this error and got this error message: The content value must be a string at least one character in length.,Recommend double-checking to make sure your code is not violating any of those requirements and, if not, filing a support ticket to further debug the request.,I am having the same error using flask-sendgrid. I have the latest version of sendgrid installed. When launching my flask server, I can send one email fine then when I request to send another one it fails.,Thanks @linehammer, I figured that out ? As I stated in my other issue (sendgrid/python-http-client#133), it seems that flask-sendgrid send twice the to parametter after the second request.

sudo pip3 install sendgrid

Answer by Beatrice Dunlap

The Box APIs uses HTTP status codes to communicate if a request
has been successfully processed or not.,Please check our Developer Troubleshooting Articles
for solution to common errors encountered when working with the Box APIs.,Please see the Client Error resource for more details.,Code samples provided under Unilicense

{
  "type": "error",
  "status": 400,
  "code": "bad_digest",
  "help_url": "http://developers.box.com/docs/#errors",
  "message": "The specified content-md5 did not match what we received",
  "request_id": "abcdef123456"
}

Answer by Zahra Salgado

The Client application gets the following response code:,400 Bad request — plain HTTP request sent to HTTPS port,400 Bad request — SSL certificate error,The client application receives an HTTP 400 — Bad request response with the
message «The SSL certificate error». This error is typically sent by the Edge Router
in a two way TLS setup enabled for the incoming connection to Apigee Edge.

The Client application gets the following response code:

HTTP/1.1 400 Bad Request

Followed by the below HTML error page:

<html>
  <head>
    <title>400 The SSL certificate error</title>
  </head>
  <body bgcolor="white">
    <center> <h1>400 Bad Request</h1>
    </center>
    <center>The SSL certificate error</center>
    <hr>
    <center>nginx</center>
  </body>
</html>

Typically a virtual host for two-way TLS communication looks as follows:

<VirtualHost name="myTLSVHost">
    <HostAliases>
        <HostAlias>api.myCompany.com</HostAlias>
    </HostAliases>
    <Port>443</Port>
    <SSLInfo>
        <Enabled>true</Enabled>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <KeyStore>ref://myKeystoreRef</KeyStore>
        <KeyAlias>myKeyAlias</KeyAlias>
        <TrustStore>ref://myTruststoreRef</TrustStore>
    </SSLInfo>
</VirtualHost>

Once you’ve decided where you would like to capture TCP/IP packets, use the following
tcpdump
command to capture TCP/IP packets:

tcpdump -i any -s 0 host <IP address> -w <File name>

Typically a virtual host for two-way TLS communication looks as follows:

    <VirtualHost name="myTLSVHost">
        <HostAliases>
            <HostAlias>api.myCompany.com</HostAlias>
        </HostAliases>
        <Port>443</Port>
        <SSLInfo>
            <Enabled>true</Enabled>
            <ClientAuthEnabled>true</ClientAuthEnabled>
            <KeyStore>ref://myKeystoreRef</KeyStore>
            <KeyAlias>myKeyAlias</KeyAlias>
                <TrustStore>ref://myCompanyTruststoreRef</TrustStore>
        </SSLInfo>
    </VirtualHost>

Typically a virtual host for two-way TLS communication looks as follows:

    <VirtualHost name="myTLSVHost">
        <HostAliases>
            <HostAlias>api.myCompany.com</HostAlias>
        </HostAliases>
        <Port>443</Port>
        <SSLInfo>
            <Enabled>true</Enabled>
            <ClientAuthEnabled>true</ClientAuthEnabled>
            <KeyStore>ref://myKeystoreRef</KeyStore>
            <KeyAlias>myKeyAlias</KeyAlias>
            <TrustStore>ref://myCompanyTruststoreRef</TrustStore>
        </SSLInfo>
    </VirtualHost>

openssl

openssl -in <OrgName_envName_vhostName-client.pem> -text -noout

Restart the Router to ensure the latest Certificates are loaded using the below step:

apigee-service edge-router restart

Answer by Ember Nava

The following table lists all the codes that can appear as code attribute of an <error> element if an error has occurred. ,If error messages have been translated, they are returned in the language that’s set in the Accept-Language header of the request. For example, if the headers include Accept-Language: de-de, error messages are returned in German. ,Note: You should not rely on specific text appearing in the <detail> element of an error response. Instead, test the value of the error code attribute to determine why an operation failed.,An HTTP status code of 404 for the response tells you that the operation was not successful because a resource could not be found. In that case, the response body might look like the following example:

For error conditions, the response body also includes an XML block that provides details about the error. For example, if the HTTP response was 404, the response body provides details about what resource in particular was not found. Imagine that you send the following PUT request in order to update information for a user:

http://your-server/api/3.13/sites/9a8b7c6d5-e4f3-a2b1-c0d9-e8f7a6b5c4d/users/9f9e9d9c8-b8a8-f8e7-d7c7-b7a6f6d6e6d 

http://your-server/api/3.13/sites/9a8b7c6d5-e4f3-a2b1-c0d9-e8f7a6b5c4d/users/9f9e9d9c8-b8a8-f8e7-d7c7-b7a6f6d6e6d

Answer by Ezra Mora

Errors in Microsoft Graph are returned using standard HTTP status codes, as well as a JSON error response object.,The following table lists and describes the HTTP status codes that can be returned.,The error resource is returned whenever an error occurs in the processing of a request.,The code property contains one of the following possible values. Your apps should be
prepared to handle any one of these errors.

The error response is a single JSON object that contains a single property
named error. This object includes all the details of the error. You can use the information returned here instead of or in addition to the HTTP status code. The following is an example of a full JSON error body.

{
  "error": {
    "code": "invalidRange",
    "message": "Uploaded fragment overlaps with existing data.",
    "innerError": {
      "requestId": "request-id",
      "date": "date-time"
    }
  }
}

The error resource is composed of these resources:

{
  "error": { "@odata.type": "odata.error" }  
}

Inside the error response is an error resource that includes the following
properties:

{
  "code": "string",
  "message": "string",
  "innererror": { "@odata.type": "odata.error" }
}

To verify that an error object is an error you are expecting, you must loop
over the innererror objects, looking for the error codes you expect. For example:

public bool IsError(string expectedErrorCode)
{
    OneDriveInnerError errorCode = this.Error;
    while (null != errorCode)
    {
        if (errorCode.Code == expectedErrorCode)
            return true;
        errorCode = errorCode.InnerError;
    }
    return false;
}
Источник

Понравилась статья? Поделить с друзьями:
  • Ошибка 400 python
  • Ошибка 400 post запрос что означает
  • Ошибка 400 сериал
  • Ошибка 400 ростелеком
  • Ошибка 400 роблокс что это