On Mon, Dec 4, 2017 at 10:27 AM, Kyle Hamilton <aerow...@gmail.com> wrote:
> SSL alert number 48 is specified in the documents that define SSL/TLS. > It is the code for "unknown_ca", which means that verification failed > because it didn't get set up with the correct CA to verify against. > You might wish to look up SSL_CTX_load_verify_locations(3). There may > also be other API calls which can load the context with certificates > to verify against. > Ok I understand that, but what could be wrong with the certificates that I generate with the commands that I told in the previous message? Kind regards. > > You can get a list of the alert numbers from RFC 5246, available from > (among other places) https://www.ietf.org/rfc/rfc5246.txt (also > available as a PDF from https://www.ietf.org/rfc/rfc5246.txt.pdf). > > -Kyle H > > On Mon, Dec 4, 2017 at 12:10 AM, <wizard2...@gmail.com> wrote: > > Hi , > > > > Please see in attach the files that I'm using. > > I generate the certificates with the following commands: > > > > ## Create CA > > openssl genrsa -out ca.key 4096 > > openssl req -new -x509 -days 365 -key ca.key -out ca.crt > > openssl x509 -in ca.crt -out ca.pem -outform PEM > > > > ## Create the Server Key and CSR > > openssl genrsa -out server.key 4096 > > openssl req -new -key server.key -out server.csr > > openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key > > -set_serial 01 -out server.crt > > openssl x509 -in server.crt -out server.pem -outform PEM > > > > ## Create the Client Key and CSR > > openssl genrsa -out client.key 4096 > > openssl req -new -key client.key -out client.csr > > openssl x509 -req -days 365 -in client.csr -CA ca.crt -CAkey ca.key > > -set_serial 01 -out client.crt > > openssl x509 -in client.crt -out client.pem -outform PEM > > > > > > I left the default value of each question that openssl ask when it's > > creating the certificates like Country, City, CN, etc. Like this way: > >> > >> openssl req -new -key server.key -out server.csr > >> > >> You are about to be asked to enter information that will be incorporated > >> > >> into your certificate request. > >> > >> What you are about to enter is what is called a Distinguished Name or a > >> DN. > >> > >> There are quite a few fields but you can leave some blank > >> > >> For some fields there will be a default value, > >> > >> If you enter '.', the field will be left blank. > >> > >> ----- > >> > >> Country Name (2 letter code) [AU]: > >> > >> State or Province Name (full name) [Some-State]: > >> > >> Locality Name (eg, city) []: > >> > >> Organization Name (eg, company) [Internet Widgits Pty Ltd]: > >> > >> Organizational Unit Name (eg, section) []: > >> > >> Common Name (e.g. server FQDN or YOUR name) []: > >> > >> Email Address []: > >> > >> Please enter the following 'extra' attributes > >> > >> to be sent with your certificate request > >> > >> A challenge password []: > >> > >> An optional company name []: > > > > > > Thanks. > > Kind regards. > > > > > > On Thu, Nov 30, 2017 at 2:45 PM, Jan Just Keijser <janj...@nikhef.nl> > wrote: > >> > >> Hi, > >> > >> On 29/11/17 14:37, wizard2...@gmail.com wrote: > >> > >> Hi JJK, > >> > >> I test you function and I've got this result: > >>> > >>> ok = 0 > >>> cert DN: /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd > >>> ok = 1 > >>> cert DN: /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd > >> > >> > >> Why I see this 2 time? > >> When I create the certificates I didn't fill with any special > information, > >> just type enter in every question that is made. Did you think this could > >> cause this issue? > >> > >> > >> what you should have seen is the certificate stack, starting with the > CA, > >> and then the client cert, e.g. > >> > >> Connection accept... > >> ok = 1 > >> cert DN: /C=US/O=Cookbook 2.4/CN=Cookbook 2.4 > >> CA/emailAddress=open...@example.com > >> ok = 1 > >> cert DN: /C=US/O=Cookbook 2.4/CN=client1 > >> > >> > >> so I suspect that your ca.crt on the server side is not specified > >> correctly. > >> You may also send me your ca.crt, server.{crt,key} and client.{crt,key} > >> files privately, and I will run the same test using your set of > >> certificates. > >> > >> HTH, > >> > >> JJK > >> > >> > >> > >> > >> On Wed, Nov 29, 2017 at 8:56 AM, Jan Just Keijser <janj...@nikhef.nl> > >> wrote: > >>> > >>> Hi, > >>> > >>> On 28/11/17 11:03, wizard2...@gmail.com wrote: > >>> > >>> Hi there. > >>> > >>> I guess my problem is really related to verify callback on > >>> SSL_CTX_set_verify function. > >>> I just add to my code a dummy callback returning 1 and everything works > >>> properly. > >>> > >>>> > >>>> int verify_callback (int ok, X509_STORE_CTX *ctx); > >>>> int verify_callback (int ok, X509_STORE_CTX *ctx) > >>>> { > >>>> printf("Verification callback OK!\n"); > >>>> return 1; > >>>> } > >>>> ... > >>>> SSL_CTX_set_verify(ssl_server_ctx, SSL_VERIFY_PEER | > >>>> SSL_VERIFY_FAIL_IF_NO_PEER_CERT, dtls_verify_callback); > >>>> ... > >>> > >>> > >>> The problem is that error don't tell much information about what's > really > >>> going on or what's really missing. > >>> Thanks for your help. > >>> > >>> Now you've effectively disabled all security :) > >>> > >>> Try adding this to the verify_callback > >>> > >>> > >>> static int verify_callback(int ok, X509_STORE_CTX *ctx) > >>> { > >>> X509 *cert = NULL; > >>> char *cert_DN = NULL; > >>> > >>> printf("ok = %d\n", ok); > >>> cert = X509_STORE_CTX_get_current_cert(ctx); > >>> cert_DN = X509_NAME_oneline( X509_get_subject_name( cert ), NULL, 0 > >>> ); > >>> printf( "cert DN: %s\n", cert_DN); > >>> > >>> } > >>> > >>> > >>> that way, you will know whether your server is processing the right > >>> certificate chain. > >>> > >>> HTH, > >>> > >>> JJK > >>> > >> > >> > > > > > > -- > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > >
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
