[openssl-users] SSL alert number 48

Mon Dec 4 10:51:48 UTC 2017

On Mon, Dec 4, 2017 at 10:27 AM, Kyle Hamilton <aerowolf at 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,  <wizard2010 at 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 <janjust at nikhef.nl>
> wrote:
> >>
> >> Hi,
> >>
> >> On 29/11/17 14:37, wizard2010 at 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=openvpn at 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 <janjust at nikhef.nl>
> >> wrote:
> >>>
> >>> Hi,
> >>>
> >>> On 28/11/17 11:03, wizard2010 at 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171204/a99abff3/attachment-0001.html>