Hi Mbed TLS list,
I’d just like to introduce myself to the wider Mbed TLS community.
I’ve recently joined the Mbed TLS team as the Engineering Manager for the Arm team. Although I’m new to this project, I’m not new to Arm having worked here for a while on a number of closed and open source library projects.
I look forward to working with you, and meeting some of you on our regular community calls.
Cheers,
Nathan.
p.s. my GitHub usid is nSircombe (https://github.com/nSircombe)
hello：
Recently, I am transplanting mbedtls from a 32-bit system to a 64-bit system. The compilation operating system is ubuntu20.4. The screenshot below is the code I use mbedtls(version number: 2.24.0). In the API mbedtls_rsa_gen_key implementation, there is a line of code that is ""MBEDTLS_MPI_CHK( mbedtls_mpi_lset( &ctx ->E, exponent ) );"", the program crashed at the memset in mbedtls_mpi_set during execution. This has not happened on 32-bit platforms before, so I would like to ask whether it has something to do with the platform used or whether I call the API. It’s a question about how to use it, thank you very much
Hi, I am trying to identify the API available by looking up exported symbols from the built shared libraries libmbedcrypto.so ,libmbedtls.so and libmbedx509.so. I noticed that many of the exported functions are not documented here https://mbed-tls.readthedocs.io/projects/api/en/development/ . My question really is, are those functions exported through the shared libraries intended to be so ? For example, function mbedtls_mpi_core_add does not seem to be part of the API but it is exported. Is this intentional ? It's not uncommon that functions would be exported but not part of the API, I just wanted to get some clarification if possible regarding the reasons for doing so in the case of MbedTLS. Thanks Ahmed
Hi,
I am sorry but I need to know test case scenarios to verify what is
supported in the recent MBedTLS stack - what should be tested.
Objective is that we cover MBedTLS code the maximum.
Since I am a new learner, I need to build the test cases from
scratch. So I thought to first find from stack what TLS ciphers suites
/ digest it supports, what are the different keysize, and protocols -
TLSvX (where x=1,2 or 3). Then build certificates related to the same
and verify the data as found. Are there other ways to find different
features in the current MBedTLs stack and verify each one of them?
Is this approach the right way - do we have known test case scenarios
to verify? Any other additional help will aid us out.
Thanks in advance.
Regards,
Prakash
Hi All,
This is going out to all the primary TF maillists.
It's a gentle reminder that a TF Discord channel has been created for all
chat communications in the TF ecosystem. All TF participants are
encouraged to join.
Instructions on how to join can be found here:
https://www.trustedfirmware.org/faq/ <https://www.trustedfirmware.org/faq/>
[image: Screenshot 2024-04-17 at 7.08.01 AM.png]
Please let me know if you have any questions,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Hello,
I am trying to add TLS 1.3 support to a curl project
(https://github.com/MAntoniak/curl). As a result, it has two questions.
The first refers to the error code
MBEDTLS_ERR_SSL_RECEIVED_NEW_SESSION_TICKET. This suggests an error
receiving a new session ticket. I couldn't find anything else in the
documentation. However, in the ssl_cllient2.c example application (line
2638), this code is used as a message to the application about a new
session ticket. This makes me unsure whether it would be correct to
continue receiving application data normally.
The second question relates to the receipt of tickets. The curl project
does not store session tickets, so it uses the
MBEDTLS_SSL_SESSION_TICKETS_DISABLED flag. If this is the case, why do
we nevertheless receive a new ticket from the server?
Thank you for your reply.
Michał Antoniak
Hello,
I have an implementation in OpenSSL and am trying to recreate it using
MbedTLS. One of the differences in these two I have yet to overcome is
the following:
Is there a way to treat mbedtls_x509_crt simply as a certificate store?
Say I have some PEM data, parse it into a temporary mbedtls_x509_crt and
then I would like to append this certificate to said mbedtls_x509_crt
certificate store.
The following is stated in the docs of mbedtls_x509_crt:
> struct mbedtls_x509_crt *next
Next certificate in the linked list that constitutes the CA chain.
NULL indicates the end of the list. Do not modify this field directly.
Is there a way to achieve this if it's advised not to modify the field
directly?
Thank you in advance,
Roman.
Hey All,
I am trying to generate ECDSA public-private key pair for self-signed
certificate, and came across these examples
In gen_key.c
<https://github.com/Mbed-TLS/mbedtls/blob/bee96566dac936e7fdfa7aa18b6a1f6767…>,
"mbedtls_ecp_gen_key()" is used
In ecdsa.c
<https://github.com/Mbed-TLS/mbedtls/blob/bee96566dac936e7fdfa7aa18b6a1f6767…>,
"mbedtls_ecdsa_genkey()" is used.
My questions are:
- Which function should be used? (It seems mbedtls_ecdsa_genkey() is
just a wrapper of mbedtls_ecp_gen_key()?)
- If using mbedtls_ecdsa_genkey(), what are the steps to write the
public key into PEM format? (My understanding is that I define a
mbedtls_pk_context, and convert its address into mbedtls_ecdsa_context *,
and pass the pointer into mbedtls_ecdsa_genkey, and then call
mbedtls_ecdsa_genkey(), is this correct?)
Thanks,
Tom
Hi Satya,
Is this issue related to the one described in your previous email “[mbed-tls] EAP TLS - TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Unknown CA)”?
Kind regards,
Janos
From: Satya Prakash Prasad <satyaprakash.developer.unix(a)gmail.com>
Date: Friday, 12 April 2024 at 16:27
To: Janos Follath <Janos.Follath(a)arm.com>
Subject: Re: [mbed-tls] CA Unknown Certificate
Hi Janos,
Kindly note that I have already provided the same in my initial email. Please refer the same for your reference:
Please note that we need to give CN value different for Root and Server / Client (since I am trying got mutual trusted certificate. You can also verify the same in below way:
First console :
# openssl s_server -cert crt1/server.crt -key crt1/server.key -WWW -port 12345 -CAfile crt1/trusted_ca.eap.pem -verify_return_err
or -Verify 1
verify depth is 1, must return a certificate
Using default temp DH parameters
ACCEPT
Second Console:
#touch test.txt
# openssl s_server -cert crt1/server.crt -key crt1/server.key -WWW -port 12345 -CAfile crt1/trusted_ca.eap.pem -verify_return_err
or -Verify 1
verify depth is 1, must return a certificate
Using default temp DH parameters
ACCEPT
On First Console we receive:
# openssl s_server -cert crt1/server.crt -key crt1/server.key -WWW -port 12345 -CAfile crt1/trusted_ca.eap.pem -verify_return_err
or -Verify 1
verify depth is 1, must return a certificate
Using default temp DH parameters
ACCEPT
depth=1 C = US, ST = CA, L = Somewhere, O = Someone, CN = FoobarCA
verify return:1
depth=0 C = US, ST = CA, L = Somewhere, O = Someone, CN = Foobar
verify return:1
FILE:test.txt
Root CA Key
# openssl genrsa -des3 -out ca.key.pem 2048
Generating RSA private key, 2048 bit long modulus (2 primes)
..+++++
....+++++
e is 65537 (0x010001)
Enter pass phrase for ca.key.pem:^1234^
Verifying - Enter pass phrase for ca.key.pem:^1234^
Server Private Key
# openssl genrsa -out server.key.pem 2048
Generating RSA private key, 2048 bit long modulus (2 primes)
........................................+++++
.................................................................................................+++++
e is 65537 (0x010001)
Client Private Key
# openssl genrsa -out client.key.pem 2048
Generating RSA private key, 2048 bit long modulus (2 primes)
...............................+++++
..........................+++++
e is 65537 (0x010001)
Root CA Certificate from Root CA Key
# openssl req -x509 -new -nodes -key ca.key.pem -sha256 -days 365 -out
ca.cert.pem -subj /C=US/ST=CA/L=Somewhere/O=Someone/CN=FoobarCA
Enter pass phrase for ca.key.pem:^1234^
Server CSR & Certificate from Server Private Key
# openssl req -new -sha256 -key server.key.pem -subj
/C=US/ST=CA/L=Somewhere/O=Someone/CN=Foobar -out server.csr
# openssl x509 -req -in server.csr -CA ca.cert.pem -CAkey ca.key.pem
-CAcreateserial -out server.cert.pem -days 365 -sha256
Signature ok
subject=C = US, ST = CA, L = Somewhere, O = Someone, CN = Foobar
Getting CA Private Key
Enter pass phrase for ca.key.pem:^1234^
Client CSR & Certificate from Client Private Key
# openssl req -new -sha256 -key client.key.pem -subj
/C=US/ST=CA/L=Somewhere/O=Someone/CN=Foobar -out client.csr
# openssl x509 -req -in client.csr -CA ca.cert.pem -CAkey ca.key.pem
-CAcreateserial -out client.cert.pem -days 365 -sha256
Signature ok
subject=C = US, ST = CA, L = Somewhere, O = Someone, CN = Foobar
Getting CA Private Key
Enter pass phrase for ca.key.pem:^1234^
Regards,
Prakash
On Fri, Apr 12, 2024 at 5:55 PM Janos Follath <Janos.Follath(a)arm.com<mailto:Janos.Follath@arm.com>> wrote:
Hi Prakash,
Thank you for sharing the details about how you generated the certificates. Could you please share the command line for the server and the client as well?
Kind regards,
Janos
From: Satya Prakash Prasad via mbed-tls <mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>>
Date: Friday, 12 April 2024 at 05:03
To: mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> <mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>>
Subject: [mbed-tls] CA Unknown Certificate
Hi,
Please note that while using MBedTLS 3.6.0, when we are trying to
verify server / client connection using self-signed mutually trusted
certificates we are always getting a CA Unknown Certificate error code
46 alert message.
Root CA Key
# openssl genrsa -des3 -out ca.key.pem 2048
Generating RSA private key, 2048 bit long modulus (2 primes)
..+++++
....+++++
e is 65537 (0x010001)
Enter pass phrase for ca.key.pem:^1234^
Verifying - Enter pass phrase for ca.key.pem:^1234^
Server Private Key
# openssl genrsa -out server.key.pem 2048
Generating RSA private key, 2048 bit long modulus (2 primes)
........................................+++++
.................................................................................................+++++
e is 65537 (0x010001)
Client Private Key
# openssl genrsa -out client.key.pem 2048
Generating RSA private key, 2048 bit long modulus (2 primes)
...............................+++++
..........................+++++
e is 65537 (0x010001)
Root CA Certificate
# openssl req -x509 -new -nodes -key ca.key.pem -sha256 -days 365 -out
ca.cert.pem -subj /C=US/ST=CA/L=Somewhere/O=Someone/CN=FoobarCA
Enter pass phrase for ca.key.pem:^1234^
Server CSR & Certificate
# openssl req -new -sha256 -key server.key.pem -subj
/C=US/ST=CA/L=Somewhere/O=Someone/CN=Foobar -out server.csr
# openssl x509 -req -in server.csr -CA ca.cert.pem -CAkey ca.key.pem
-CAcreateserial -out server.cert.pem -days 365 -sha256
Signature ok
subject=C = US, ST = CA, L = Somewhere, O = Someone, CN = Foobar
Getting CA Private Key
Enter pass phrase for ca.key.pem:^1234^
Client CSR & Certificate
# openssl req -new -sha256 -key client.key.pem -subj
/C=US/ST=CA/L=Somewhere/O=Someone/CN=Foobar -out client.csr
# openssl x509 -req -in client.csr -CA ca.cert.pem -CAkey ca.key.pem
-CAcreateserial -out client.cert.pem -days 365 -sha256
Signature ok
subject=C = US, ST = CA, L = Somewhere, O = Someone, CN = Foobar
Getting CA Private Key
Enter pass phrase for ca.key.pem:^1234^
So we have used Root CA Certificatet as trusted certificate but during
handshake steps we see client reporting "Certificate Unknown'' alert
error message 46?
TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Certificate Unknown)
Description: Certificate Unknown (46)
Can you please let us know the issue we are doing in creating the
certificates or it can also be some wrong steps / configuration while
compiling the 3.6.0 release?
Regards,
Prakash
--
mbed-tls mailing list -- mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>
To unsubscribe send an email to mbed-tls-leave(a)lists.trustedfirmware.org<mailto:mbed-tls-leave@lists.trustedfirmware.org>
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
