[openssl-users] SSL Handshake with TPM using TPM Engine

2017-12-04 Thread Devang Kubavat 
Hi All,



*SSL handshake with TPM using TPM Engine: *I am generating the RSA keys in
TPM and private key will never come out from TPM

I want to do SSL handshake with this scenario.
Can you please point out me in SSL handshake which functions are using the
RSA private key? So that, I can register those functions in TPM Engine to
perform RSA private key related operation.

Is there any reference implementation for SSL handshake using TPM via TPM
Engine?

Regards,
Digant
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Forthcoming OpenSSL release

2017-12-04 Thread Matt Caswell 
Forthcoming OpenSSL release
===

The OpenSSL project team would like to announce the forthcoming release
of OpenSSL version 1.0.2n. There will be no OpenSSL 1.1.0 release at
this time.

This release will be made available on 7th December 2017 between
approximately 1300-1700 UTC.

This is a security-fix release. The highest severity issue fixed in this
release is MODERATE.

Please also note that, as per our previous announcements, support for
1.0.1 ended on 31st December 2016.

Yours

The OpenSSL Project Team



signature.asc
Description: OpenPGP digital signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] FIPS certification for openssl

2017-12-04 Thread Michael Wojcik 
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Salz, Rich via openssl-users
> Sent: Saturday, December 02, 2017 11:42
> 
> >My personal priority list for OpenSSL is bug fixes and code cleanup 
> > (static
> > and dynamic analysis of the 1.1.x codebase would be good, and one of these
> > days I'll get around to doing it myself),
> 
> We do run coverity weekly, and anyone can sign up to see the results BTW

Oh, that's right. I knew that at one time (probably when it was announced), but 
I forgot.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 


-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] SSL alert number 48

2017-12-04 Thread wizard2010 
On Mon, Dec 4, 2017 at 10:27 AM, Kyle Hamilton  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,   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 
> 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 
> >> 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);
>  ...
> >>>

Re: [openssl-users] SSL alert number 48

2017-12-04 Thread Kyle Hamilton 
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.

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,   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  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 
>> 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(

Re: [openssl-users] ASN1 & Recursive Structures definition

2017-12-04 Thread Richard Levitte 
Ah, sorry then, I may have been wrong.  The forward declaration that's
actually needed seems to be this (one for each applicable type):

DECLARE_ASN1_ITEM(TEST)

(I'm digging through the ASN.1 stuff myself, slowly learning)

Cheers,
Richard

In message <0089b413-278e-34b1-32b3-2e71b48e5...@openca.org> on Sun, 3 Dec 2017 
11:37:56 -0700, "Dr. Pala"  said:

madwolf> Hi Richard, all,
madwolf> 
madwolf> I tried to do the forward declaration also for the TEST_SIGNATURE 
together with the TEST one, but
madwolf> that did not really work :( It is still complaining about the use of 
'sizeof' on an incomplete type. In
madwolf> particular, the two errors are:
madwolf> 
madwolf>  src/ocspv2/: error: use of undeclared identifier 'TEST_it'
madwolf>  ASN1_EXP_SEQUENCE_OF_OPT(TEST_TBS, otherTests, TEST, 5),
madwolf>  ^
madwolf> 
madwolf>  and
madwolf> 
madwolf>  src/ocspv2/: error: invalid application of 'sizeof' to an 
incomplete type 'const
madwolf>  ASN1_TEMPLATE []'
madwolf>  } ASN1_SEQUENCE_END(TEST_TBS)
madwolf>  ^~~~
madwolf> 
madwolf> I guess I need to checkout the macros a bit more.. :D
madwolf> 
madwolf> Question: does anybody know if there is any other structure already 
implemented in OpenSSL that
madwolf> resembles the one I am trying to do here? I tried to look for 
something similar, but no success.. :D
madwolf> 
madwolf> If there is no easy answer, I guess I will have to either change the 
envisioned approach (maybe
madwolf> introducing an intermediate data structure of some kind..?) or use the 
ASN1_ANY approach.
madwolf> 
madwolf> Cheers,
madwolf> Max
madwolf> 
madwolf> On 12/2/17 4:54 AM, Richard Levitte wrote:
madwolf> 
madwolf>  In message  on Fri, 
1 Dec 2017 20:22:09 -0700,
madwolf>  "Dr. Pala"  said:
madwolf> 
madwolf> madwolf> Hi Richard,
madwolf> madwolf>
madwolf> madwolf> thanks :D That worked. I have a new challenge for you now. 
Here's what
madwolf> madwolf> I am trying to do:
madwolf> madwolf>
madwolf> madwolf> ASN1_SEQUENCE(TEST);
madwolf> madwolf> ASN1_SEQUENCE(TBS_TEST) = {
madwolf> madwolf> ASN1_SIMPLE(TBS_TEST, version, ASN1_INTEGER),
madwolf> madwolf> ASN1_EXP_SEQUENCE_OF_OPT(TBS_TEST, otherTests, TEST, 0)
madwolf> madwolf> } ASN1_SEQUENCE_END(TEST)
madwolf> madwolf>
madwolf> madwolf> IMPLEMENT_ASN1_FUNCTIONS(TBS_TEST) [**]
madwolf> madwolf>
madwolf> madwolf> ASN1_SEQUENCE(TEST) = {
madwolf> madwolf> ASN1_SIMPLE(TEST, tbsTest, ASN1_INTEGER),
madwolf> madwolf> ASN1_EXP_OPT(TEST, optionalSignature, TEST_SIGNATURE, 0)
madwolf> madwolf> } ASN1_SEQUENCE_END(TEST)
madwolf> madwolf>
madwolf> madwolf> IMPLEMENT_ASN1_FUNCTIONS(TEST) [**]
madwolf> madwolf>
madwolf> madwolf> In this case, the difference is that TBS_TEST has, inside the
madwolf> madwolf> otherTests that are of type TEST. The TEST is built out of a 
tbsTest
madwolf> madwolf> and an optionalSignature - but it is defined after TBS_TEST.
madwolf> madwolf>
madwolf> madwolf> What to do in this case ?
madwolf> 
madwolf> It seems to me that you need to do some kind of forward declaration of
madwolf> TEST_SIGNATURE as well, before the construction of TEST.  (also, to be
madwolf> picky, you need to make sure that ASN1_SEQUENCE(TBS_TEST) is ended
madwolf> with ASN1_SEQUENCE_END(TBS_TEST), not ASN1_SEQUENCE_END(TEST))
madwolf> 
madwolf> Cheers,
madwolf> Richard
madwolf> 
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] SSL alert number 48

2017-12-04 Thread wizard2010 
Hi ,

Please see in attach the files that I'm using.
I generate the certificates with the following commands:


   1. ## Create CA
   2. openssl genrsa -out ca.key 4096
   3. openssl req -new -x509 -days 365 -key ca.key -out ca.crt
   4. openssl x509 -in ca.crt -out ca.pem -outform PEM
   5.


   1. ## Create the Server Key and CSR
   2. openssl genrsa -out server.key 4096
   3. openssl req -new -key server.key -out server.csr
   4. openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key
   -set_serial 01 -out server.crt
   5. openssl x509 -in server.crt -out server.pem -outform PEM
   6.


   1. ## Create the Client Key and CSR
   2. openssl genrsa -out client.key 4096
   3. openssl req -new -key client.key -out client.csr
   4. openssl x509 -req -days 365 -in client.csr -CA ca.crt -CAkey ca.key
   -set_serial 01 -out client.crt
   5. 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  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=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 
> 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
>>
>>
>
>


ca.crt
Description: application/pkix-cert


ca.key
Description: application/iwork-keynote-sffkey


ca.pem
Description: application/x509-ca-cert


client.crt
Description: application/pkix-cert


client.csr
Description: application/pkcs10


client.key
Description: application/iwork-keynote-sffkey


client.pem
Description: application/x509-ca-cert


server.crt
Description: application/pkix-cert


server.csr
Description: application/pkcs10


server.key
Description: application/iwork-keynote-sffkey


server.pem
Description: application/x509-ca-cert
-- 
openssl-users mailing list