> 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
