0x2700 - X509 - Certificate verification failed, e.g. CRL, CA or signature check failed #139

fibjs · 2014-11-05T15:49:46Z

ssl client connect error:

./ssl_client2 server_name=openapi.baidu.com server_port=443 ca_file=certdata.txt  debug_level=1

certdata.txt

result:

  . Seeding the random number generator... ok
  . Loading the CA root certificate ... ok (0 skipped)
  . Loading the client cert. and key... ok
  . Connecting to tcp/openapi.baidu.com/443 ... ok
  . Setting up the SSL/TLS structure... ok
  . Performing the SSL/TLS handshake...
Verify requested for (Depth 2):
cert. version     : 3
serial number     : 25:0C:E8:E0:30:61:2E:9F:2B:89:F7:05:4D:7C:F8:FD
issuer name       : C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
subject name      : C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2006 VeriSign, Inc. - For authorized use only, CN=VeriSign Class 3 Public Primary Certification Authority - G5
issued  on        : 2006-11-08 00:00:00
expires on        : 2021-11-07 23:59:59
signed using      : RSA with SHA1
RSA key size      : 2048 bits
basic constraints : CA=true
key usage         : Key Cert Sign, CRL Sign
ext key usage     : TLS Web Server Authentication, TLS Web Client Authentication, Code Signing, ???, ???
  ! self-signed or not signed by a trusted CA

Verify requested for (Depth 1):
cert. version     : 3
serial number     : 64:1B:E8:20:CE:02:08:13:F3:2D:4D:2D:95:D6:7E:67
issuer name       : C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2006 VeriSign, Inc. - For authorized use only, CN=VeriSign Class 3 Public Primary Certification Authority - G5
subject name      : C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)10, CN=VeriSign Class 3 International Server CA - G3
issued  on        : 2010-02-08 00:00:00
expires on        : 2020-02-07 23:59:59
signed using      : RSA with SHA1
RSA key size      : 2048 bits
basic constraints : CA=true, max_pathlen=0
subject alt name  :
key usage         : Key Cert Sign, CRL Sign
ext key usage     : TLS Web Server Authentication, TLS Web Client Authentication, ???, ???
  This certificate has no flags

Verify requested for (Depth 0):
cert. version     : 3
serial number     : 2D:73:DA:EE:3D:44:A1:DD:F6:65:13:18:39:20:58:00
issuer name       : C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)10, CN=VeriSign Class 3 International Server CA - G3
subject name      : C=CN, ST=Beijing, L=Beijing, O=BeiJing Baidu Netcom Science Technology Co., Ltd, OU=service operation department, OU=Organization and domain(s) authenticated by iTrus China, CN=openapi.baidu.com
issued  on        : 2014-10-31 00:00:00
expires on        : 2015-11-02 23:59:59
signed using      : RSA with SHA1
RSA key size      : 2048 bits
basic constraints : CA=false
subject alt name  : openapi.baidu.com
key usage         : Digital Signature, Key Encipherment
ext key usage     : TLS Web Server Authentication, TLS Web Client Authentication, ???
  This certificate has no flags
 failed
  ! ssl_handshake returned -0x2700
    Unable to verify the server's certificate. Either it is invalid,
    or you didn't set ca_file or ca_path to an appropriate value.
    Alternatively, you may want to use auth_mode=optional for testing purposes.

Last error was: -0x2700 - X509 - Certificate verification failed, e.g. CRL, CA or signature check failed

The text was updated successfully, but these errors were encountered:

pjbakker · 2014-11-07T13:40:17Z

This fails because you don't provide use the 'top', but the one below.

Try this one instead.

fibjs · 2014-11-07T14:46:32Z

thanks, it's solved.

FarhanAhmad · 2017-01-03T11:25:34Z

@pjbakker whats 'top' ? Didn't understand what you meant.

pjbakker · 2017-01-03T15:06:44Z

@FarhanAhmad A certificate chain runs all the way from a child certificate to the 'top' (The CA certificate).
In case of the issue above, the CA Chain provided to the application contained the certificate up to (but not including) the 'top' certificate. Without that top certificate, the chain could not be verified in full.

That said. I believe the behaviour of verification has been modified in more recent version, so you might now be able to provide a 'middle' certificate as trusted instead. Maybe @sbutcher-arm can comment on that?

PravallikaKG · 2017-03-16T12:01:32Z

@pjbakker I am facing the similar error('-9984 - X509 - Certificate verification failed, e.g. CRL, CA or signature check failed') at 'mbedtls_ssl_handshake' call.
I am new to mbed tls, i dont know much fundamentals of it. I referred to programs/ssl/ssl_server2.c and ssl_client2.c files. Following is my scenario, please tell me if i am doing anything wrong.

I have my own ca.cert, server.cert, client.cert, server.key,client.key and ca.key files.
Following is my piece of code at server side and client side:

server partial code:

``
int ret = mbedtls_x509_crt_parse_file(&cacert, ca_file);
if (ret != 0) {
mbedtls_printf( " failed\n ! mbedtls_x509_crt_parse_file returned %d\n\n", ret );
goto exit;
}

ret = mbedtls_x509_crt_parse_file(&srvcert, server_file);
if (ret != 0) {
    mbedtls_printf( " failed\n  !  mbedtls_x509_crt_parse_file returned %d\n\n", ret );
    goto exit;
}

ret = mbedtls_pk_parse_keyfile(&pkey,serverkey_file,password);
if (ret != 0) {
    mbedtls_printf( " failed\n  !  mbedtls_pk_parse_keyfile server returned %d\n\n", ret );
    goto exit;
}

..............
..............

mbedtls_ssl_conf_ca_chain( &conf, &cacert, NULL );
if( ( ret = mbedtls_ssl_conf_own_cert( &conf, &srvcert, &pkey ) ) != 0 )
{
    mbedtls_printf( " failed\n  ! mbedtls_ssl_conf_own_cert returned %d\n\n", ret );
    goto exit;
}

if( ( ret = mbedtls_ssl_setup( &ssl, &conf ) ) != 0 )
{
    mbedtls_printf( " failed\n  ! mbedtls_ssl_setup returned %d\n\n", ret );
    goto exit;
}
........................
.....................
// Performing the SSL/TLS handshake...
while( ( ret = mbedtls_ssl_handshake( &ssl ) ) != 0 )
{
    if( ret != MBEDTLS_ERR_SSL_WANT_READ && ret != MBEDTLS_ERR_SSL_WANT_WRITE )
    {
        mbedtls_printf( " failed\n  ! mbedtls_ssl_handshake returned %d\n\n", ret );
        goto reset;
    }
}

``

Client side code:

``
ret = mbedtls_x509_crt_parse_file(&cd->ca_cert, ca_cert_filename);
if (ret != 0) {
mbedtls_printf( " failed\n ! mbedtls_x509_crt_parse_file of ca returned %d\n\n", ret );
exit(ret);
}

ret = mbedtls_x509_crt_parse_file(&cd->client_cert, client_cert_filename);
	if (ret != 0) {
    	mbedtls_printf( " failed\n  !  mbedtls_x509_crt_parse_file of client returned %d\n\n", ret );
    	exit(ret);
	}

ret = mbedtls_pk_parse_keyfile(&cd->client_pkey,client_key_filename,password);
if (ret != 0) {
	mbedtls_printf( " failed\n  !  mbedtls_pk_parse_keyfile client returned %d\n\n", ret );
	exit(ret);
}

   mbedtls_ssl_conf_authmode( &cd->conf, MBEDTLS_SSL_VERIFY_REQUIRED );
	
   mbedtls_ssl_conf_ca_chain( &cd->conf, &cd->ca_cert, NULL  );
if( ( ret = mbedtls_ssl_conf_own_cert( &cd->conf, &cd->client_cert, &cd->client_pkey ) ) != 0 )
    {
        mbedtls_printf( " failed\n  ! mbedtls_ssl_conf_own_cert returned %d\n\n", ret );
    exit(ret);
    }
	......................
    ........................
	if( ( ret = mbedtls_ssl_setup( &cd->ssl, &cd->conf ) ) != 0 )
	{
    	mbedtls_printf( " failed\n  ! mbedtls_ssl_setup returned %d\n\n", ret );
    	freeClientTLSData(ret,cd);
	exit(ret);
	}

	while( ( ret = mbedtls_ssl_handshake( &cd->ssl ) ) != 0 )
	{
    	if( ret != MBEDTLS_ERR_SSL_WANT_READ && ret != MBEDTLS_ERR_SSL_WANT_WRITE )
    	{
        		mbedtls_printf( " failed\n  ! mbedtls_ssl_handshake returned -0x%x\n\n", -ret );
        		freeClientTLSData(ret,cd);
		exit(ret);
    	}
	}

``

Please let me if i am doing anything wrong at 'mbedtls_ssl_conf_ca_chain' , 'mbedtls_ssl_conf_own_cert' calls order or if any. And also which certificates(ca, client, server certs) are mainly required at both server and client side code.

Thanks in Advance.

PravallikaKG · 2017-03-19T06:31:22Z

My issue is resolved. I am facing it because of certificates I am using are invalid

Correct and simplify block-based cipher modes

martinius96 · 2018-11-15T23:05:44Z

@PravallikaKG yes, because you haven't self-signed them.

Carmeloning · 2019-01-16T04:30:01Z

How you slove it,I meet something like it:ssl_tls.c:4643: |1| x509_verify_cert() returned -9984 (-0x2700)
mbedtls_ssl_handshake() returned -0x2700
Can you help me，thanks

RonEld · 2019-01-16T17:25:47Z

@Carmeloning certificate verification failure can happen for many reasons. For example, you haven't set the correct trusted root certificate.
The error -0x2700 is MBEDTLS_ERR_X509_CERT_VERIFY_FAILED and returned when the certificate verification fails.
You should check the verification flags as well.

martinius96 · 2019-01-16T17:29:26Z

I had similar error when i was generating Root CA certificate from 1024-bit RSA key.
I was using ESP32 board,
How did you generate it?
If u using RSA key how many bits it have?

RonEld · 2019-01-16T17:56:42Z

@martinius96
As you can see in the default profile used for certificate verification, the minimal keysize allowed is 2048 bits. This is because a 1024 bit key size is unsecure.

martinius96 · 2019-01-16T18:56:54Z

@RonEld Thanks a lot.. finally i found it in codes..
I was 3 months solving problem why it isnt working and i was using 1024-bit rsa key... :(
:D :-)

Carmeloning · 2019-01-17T01:30:05Z

@Carmeloning证书验证失败可能由于多种原因而发生。例如，您尚未设置正确的受信任根证书。证书验证失败时返回
错误-0x2700 MBEDTLS_ERR_X509_CERT_VERIFY_FAILED并返回。
您还应该检查验证标志。
I used the server to give me the root certificate in the browser test and the server handshake is able to pass，But when i use the Mbed. IT is faild and it return like this：
Starting mbed-os-example-tls/tls-client
Using Mbed OS 5.9.7
[EasyConnect] IPv4 mode
[EasyConnect] Using WiFi (ESP8266)
[EasyConnect] Connecting to WiFi GE
[EasyConnect] Connected to Network successfully
[EasyConnect] MAC address 84:0d:8e:97:40:ca
[EasyConnect] IP address 192.168.1.15
Successfully connected to 39.108.211.173 at port 443
Starting the TLS handshake...
ssl_tls.c:6717: |2| => handshake

ssl_cli.c:3386: |2| client state: 0

ssl_tls.c:2471: |2| => flush output

ssl_tls.c:2483: |2| <= flush output

ssl_cli.c:3386: |2| client state: 1

ssl_tls.c:2471: |2| => flush output

ssl_tls.c:2483: |2| <= flush output

ssl_cli.c:770: |2| => write client hello

ssl_tls.c:2764: |2| => write record

ssl_tls.c:2471: |2| => flush output

ssl_tls.c:2489: |2| message length: 189, out_left: 189

ssl_tls.c:2496: |2| ssl->f_send() returned 189 (-0xffffff43)

ssl_tls.c:2523: |2| <= flush output

ssl_tls.c:2922: |2| <= write record

ssl_cli.c:1085: |2| <= write client hello

ssl_cli.c:3386: |2| client state: 2

ssl_tls.c:2471: |2| => flush output

ssl_tls.c:2483: |2| <= flush output

ssl_cli.c:1478: |2| => parse server hello

ssl_tls.c:3809: |2| => read record

ssl_tls.c:2252: |2| => fetch input

ssl_tls.c:2412: |2| in_left: 0, nb_want: 5

ssl_tls.c:2436: |2| in_left: 0, nb_want: 5

ssl_tls.c:2438: |2| ssl->f_recv(_timeout)() returned 5 (-0xfffffffb)

ssl_tls.c:2458: |2| <= fetch input

ssl_tls.c:2252: |2| => fetch input

ssl_tls.c:2412: |2| in_left: 5, nb_want: 66

ssl_tls.c:2436: |2| in_left: 5, nb_want: 66

ssl_tls.c:2438: |2| ssl->f_recv(_timeout)() returned 61 (-0xffffffc3)

ssl_tls.c:2458: |2| <= fetch input

ssl_tls.c:3846: |2| <= read record

ssl_cli.c:1760: |2| server hello, total extension length: 17

ssl_cli.c:1949: |2| <= parse server hello

ssl_cli.c:3386: |2| client state: 3

ssl_tls.c:2471: |2| => flush output

ssl_tls.c:2483: |2| <= flush output

ssl_tls.c:4376: |2| => parse certificate

ssl_tls.c:3809: |2| => read record

ssl_tls.c:2252: |2| => fetch input

ssl_tls.c:2412: |2| in_left: 0, nb_want: 5

ssl_tls.c:2436: |2| in_left: 0, nb_want: 5

ssl_tls.c:2438: |2| ssl->f_recv(_timeout)() returned 5 (-0xfffffffb)

ssl_tls.c:2458: |2| <= fetch input

ssl_tls.c:2252: |2| => fetch input

ssl_tls.c:2412: |2| in_left: 5, nb_want: 877

ssl_tls.c:2436: |2| in_left: 5, nb_want: 877

ssl_tls.c:2438: |2| ssl->f_recv(_timeout)() returned 872 (-0xfffffc98)

ssl_tls.c:2458: |2| <= fetch input

ssl_tls.c:3846: |2| <= read record

Verifying certificate at depth 0:

cert. version : 1

serial number : 8D:9E:62:C5:CC:7A:BA:B6

issuer name : C=CN, ST=myprovince, L=mycity, O=myorganization, OU=mygroup, CN=myCA

subject name : C=CN, ST=myprovince, L=mycity, O=myorganization, OU=mygroup, CN=myServer

issued on : 2019-01-14 02:25:20

expires on : 2020-01-14 02:25:20

signed using : RSA with SHA1

RSA key size : 2048 bits

ssl_tls.c:4643: |1| x509_verify_cert() returned -9984 (-0x2700)

ssl_tls.c:4180: |2| => send alert message

ssl_tls.c:2764: |2| => write record

ssl_tls.c:2471: |2| => flush output

ssl_tls.c:2489: |2| message length: 7, out_left: 7

ssl_tls.c:2496: |2| ssl->f_send() returned 7 (-0xfffffff9)

ssl_tls.c:2523: |2| <= flush output

ssl_tls.c:2922: |2| <= write record

ssl_tls.c:4193: |2| <= send alert message

ssl_tls.c:4740: |2| <= parse certificate

ssl_tls.c:6727: |2| <= handshake

mbedtls_ssl_handshake() returned -0x2700

FAIL
ssl_tls.c:7495: |2| => free

ssl_tls.c:7560: |2| <= free

RonEld · 2019-01-17T15:24:42Z

@Carmeloning Have you checked the verification flags? They are not shown in this log.

Without too much information in this log, I can guess two possible reasons for your failure:

You haven't set the proper trusted CA certificate( certificate which has a CN "myCA" in its subject name), in mbedtls_ssl_conf_ca_chain().
You haven't defined MBEDTLS_TLS_DEFAULT_ALLOW_SHA1_IN_CERTIFICATES in your configuration. SHA1 is considered not a secure hash, and by default not allowed to be used in certificates, in Mbed TLS

Make DES self-test faster, and fix a typo

…lpers Use transcript hash helper functions in server-side postprocessing after outgoing Finished message

pjbakker closed this as completed Nov 7, 2014

mpg pushed a commit that referenced this issue Oct 30, 2018

Merge pull request #139 from ARMmbed/psa-PSA_ALG-block_cipher_padding

40363fe

Correct and simplify block-based cipher modes

Patater added a commit to Patater/mbedtls that referenced this issue Feb 10, 2020

Merge pull request Mbed-TLS#139 from Patater/des-faster-and-typo-fix

8096969

Make DES self-test faster, and fix a typo

hanno-becker pushed a commit to hanno-becker/mbedtls that referenced this issue Feb 5, 2021

Merge pull request Mbed-TLS#139 from hanno-arm/use_transcript_hash_he…

e4d603c

…lpers Use transcript hash helper functions in server-side postprocessing after outgoing Finished message

chegewara mentioned this issue Mar 20, 2021

What is "Double exception"? (IDFGH-1548) espressif/esp-idf#3810

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

0x2700 - X509 - Certificate verification failed, e.g. CRL, CA or signature check failed #139

0x2700 - X509 - Certificate verification failed, e.g. CRL, CA or signature check failed #139

fibjs commented Nov 5, 2014

pjbakker commented Nov 7, 2014

fibjs commented Nov 7, 2014

FarhanAhmad commented Jan 3, 2017

pjbakker commented Jan 3, 2017

PravallikaKG commented Mar 16, 2017 •

edited

PravallikaKG commented Mar 19, 2017

martinius96 commented Nov 15, 2018

Carmeloning commented Jan 16, 2019

RonEld commented Jan 16, 2019

martinius96 commented Jan 16, 2019 •

edited

RonEld commented Jan 16, 2019 •

edited

martinius96 commented Jan 16, 2019

Carmeloning commented Jan 17, 2019

RonEld commented Jan 17, 2019

0x2700 - X509 - Certificate verification failed, e.g. CRL, CA or signature check failed #139

0x2700 - X509 - Certificate verification failed, e.g. CRL, CA or signature check failed #139

Comments

fibjs commented Nov 5, 2014

pjbakker commented Nov 7, 2014

fibjs commented Nov 7, 2014

FarhanAhmad commented Jan 3, 2017

pjbakker commented Jan 3, 2017

PravallikaKG commented Mar 16, 2017 • edited

server partial code:

Client side code:

PravallikaKG commented Mar 19, 2017

martinius96 commented Nov 15, 2018

Carmeloning commented Jan 16, 2019

RonEld commented Jan 16, 2019

martinius96 commented Jan 16, 2019 • edited

RonEld commented Jan 16, 2019 • edited

martinius96 commented Jan 16, 2019

Carmeloning commented Jan 17, 2019

RonEld commented Jan 17, 2019

PravallikaKG commented Mar 16, 2017 •

edited

martinius96 commented Jan 16, 2019 •

edited

RonEld commented Jan 16, 2019 •

edited