I think there is an error in function mbedtls_asn1_write_algorithm_identifier (library\asn1write.c).
Depending on par_len it encodes par_len or NULL. But there is a third option.
If we look at https://tools.ietf.org/html/rfc7427#page-14 there are some algorithm identifiers which do not have parameter and NULL should not be placed.
We can see this problem when comparing what OpenSSL and Mbed TLS produces.
Mbed TLS produces following ASN.1
10:d=3 hl=2 l= 1 prim: INTEGER :00
13:d=2 hl=2 l= 3 prim: INTEGER :652040
18:d=2 hl=2 l= 12 cons: SEQUENCE
20:d=3 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256
30:d=3 hl=2 l= 0 prim: NULL
32:d=2 hl=2 l= 53 cons: SEQUENCE
OpenSSL produces following ASN.1
4:d=1 hl=4 l= 279 cons: SEQUENCE
8:d=2 hl=2 l= 3 prim: INTEGER :652040
13:d=2 hl=2 l= 10 cons: SEQUENCE
15:d=3 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256
25:d=2 hl=2 l= 53 cons: SEQUENCE
27:d=3 hl=2 l= 11 cons: SET
Problem was found when I wanted to create a CA certificate and an endpoint certificate (both with keys based on elliptic curves).
When CA certificate was created with RSA key, everything was correct.
There was no problem when endpoint certificate had key based on elliptic curves.
When I used keys based on elliptic curves with CA certificate Chrome reported NET::ERR_CERT_INVALID during SSL_do_handshake.