Hello Michael, thank you and Viktor for your fast help. Viktor annotations I don't fully understand. Sure there is the openssl test server and client, but the source code is complex for everyone who is new in this encryption tasks. But testing with openssl was a valuable notice: 1) openssl vs openssl openssl s_server -port 8080 -CAfile certs/server/ca.crt -cert certs/server/server.crt -key certs/server/server.key -Verify 99 Is this the right call for "TLS with mutual authentication", I cannot find an other parameter for SSL_VERIFY_PEER? with openssl s_client -connect localhost:8080 -CAfile certs/client/ca.crt -cert certs/client/client.crt -key certs/client/client.key it is working, and the server sees the COMMON NAME of the client (the whole certificate) 2) openssl vs myclient is working 3) myserver vs openssl (and my client) is not working In the openssl server command line I set only CAfile, cert, key and verify I believe I do this also in my source code: int verify_flags = SSL_VERIFY_PEER SSL_CTX_set_verify(srvCtx->ctx, verify_flags, NULL); char cafile[] = "/home/debdev/Projects/clearing/server/certs/client/ca.crt"; Variant 1: SSL_CTX_use_certificate_chain_file(srvCtx->ctx, cafile) Variant 2: STACK_OF(X509_NAME) *calist = SSL_load_client_CA_file(cafile); SSL_CTX_set_client_CA_list(srvCtx->ctx, calist); if (SSL_CTX_use_certificate_file(srvCtx->ctx, srvCtx->cert, SSL_FILETYPE_PEM) <= 0) if (SSL_CTX_use_PrivateKey_file(srvCtx->ctx, srvCtx->key, SSL_FILETYPE_PEM) <= 0 ) But there is still the error: tls_process_client_certificate:certificate verify failed Why? 4) I have looked into apps/s_server.c there is a ctx_set_verify_locations with the cafile information in apps.c this calls: SSL_CTX_load_verify_file, but the compiler can't find this function. Why? Thanks and sorry if I do not understand all details in the first try. Best regards Andreas Am 06.05.2020 um 21:59 schrieb Michael Wojcik: >> From: openssl-users [mailto:openssl-users-bounces@xxxxxxxxxxx] On Behalf Of >> Andreas Tengicki >> Sent: Wednesday, May 06, 2020 12:45 >> To: openssl-users@xxxxxxxxxxx >> Subject: mutual-TLS / mTLS Example with certificate problem >> >> I can not find a working mutual-TLS server/client example on github or >> the whole internet. > By "mutual-TLS" I assume you mean "TLS with mutual authentication". > > I don't know about open-source examples off the top of my head, but all the products I work on support mutual authentication. > > Oh, wait, of course I know of an open-source example. It's OpenSSL, which supports mutual authentication in the s_server and s_client apps. > >> SSL_CTX_use_certificate_chain_file(srvCtx->ctx, >> "../certs/server/ca.crt"); >> SSL_CTX_use_certificate_file(srvCtx->ctx, >> "../certs/server/server.crt", SSL_FILETYPE_PEM); > This is very likely wrong. SSL(_CTX)_use_certificate_chain_file sets the entity certificate and its (partial) chain. So when you call SSL_CTX_use_certificate_file you're overwriting the entity certificate set by use_certificate_chain_file. > > Get rid of the call to use_certificate_file and put everything the server should be sending into the chain file, in the order described in the OpenSSL documentation: entity certificate, certificate for its issuer, and so on up to and including the root. (I've just noticed the docs don't say whether use_certificate_chain_file specifies SSL_BUILD_CHAIN_FLAG_NO_ROOT when it calls add1_chain_cert, so offhand I don't know whether this will cause the root to be included in the chain the server sends. But that shouldn't really matter.) > >> ca.crt: Version: 3 (0x2) >> Serial Number: >> 5a:fc:74:e6:28:28:0e:df:5b:7a:50:9e:a8:18:e6:04:42:f0:fd:8d >> Signature Algorithm: sha256WithRSAEncryption >> Issuer: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = 42CA >> Validity Not Before: May 6 09:21:23 2020 GMT Not After : May 6 >> 09:21:23 2022 GMT >> Subject: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN >> = 42CA > Not enough information. We don't know what the Basic Constraints are for this certificate, or EKU, or whether it's actually the certificate that signed your server's entity certificate. > > More importantly, if this is the only certificate in ca.crt, which was what you passed to use_certificate_chain_file, then this was stored in the context as the entity cert, and no certificates were added to the chain. Then you overwrote the entity cert with use_certificate_file, and you still have no chain. > > (At least I believe that's what will happen; I haven't actually tried it.) > >> server.crt: Version: 1 (0x0) > X.509v1? PKIX moved to v3 in, what, 2002 (with RFC 3280)? > > I mean, X.509v1 ought to still work, but it's hardly good practice. > >> Subject: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = >> debiandevdesktop01.sdctec.lokal >> >> debiandevdesktop01.sdctec.lokal is the FQDN of the development server > And is that exactly what the client is specifying when it tries to verify the server's certificate? > >> SSL_CTX_use_certificate_chain_file(ctx, "../certs/client/ca.crt"); >> SSL_CTX_use_certificate_file(ctx, "../certs/client/client.crt", >> SSL_FILETYPE_PEM); > Same problem as above. > >> If the client connects the server there are the following errors: >> >> server: >> 139918902234240:error:1416F086:SSL >> routines:tls_process_server_certificate:certificate verify >> failed:../ssl/statem/statem_clnt.c:1915: > Is that the whole OpenSSL error stack? When reporting an OpenSSL error (from your application), you should always make sure to dump the whole stack. > > Also, a piece of advice: A good place to start when diagnosing issues like this is to swap out the server for openssl s_server, or the client for openssl s_client. s_client can give you a whole bunch of information about what the server is sending, and would have shown the chain is just the entity certificate in this case. > > -- > Michael Wojcik > Distinguished Engineer, Micro Focus > >
