On Mon, Dec 4, 2017 at 10:27 AM, Kyle Hamilton <aerowolf@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx> wrote:
>>
>> Hi,
>>
>> On 29/11/17 14:37, wizard2010@xxxxxxxxx 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@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@xxxxxxxxx>
>> wrote:
>>>
>>> Hi,
>>>
>>> On 28/11/17 11:03, wizard2010@xxxxxxxxx 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
