Re: [openssl-users] General approach for keeping a client cert from openssl

[Andy Green]

On Mon, 2016-12-19 at 10:21 -0800, Kyle Hamilton wrote:

> You cannot keep the certificate from OpenSSL, as that's the piece
> that you share with the remote side.  This contains the public key,
> and the information bound to that public key by the CA.

Right.

> However, you can keep the private key from being seen by OpenSSL.

Yes, this is the game.

>   There exists what is called an ENGINE interface to offload
> cryptographic operations to a container.  Right now,
> https://wiki.openssl.org/index.php/Creating_an_OpenSSL_Engine_to_use_
> indigenous_ECDH_ECDSA_and_HASH_Algorithms seems to be the best
> documentation available to explain the process of creating it.  

Thanks, I will start with that and try to understand it better.

> Obviously, depending on the type of key you're using, you will
> probably need to figure out the differences.

Yes, it seems it's basically overloading one or more crypto action, so
we need to match the action to what it wants to do with the cert key. 
But I guess to get started, we can do what we have code for.

Thanks again I will study it.

-Andy

> -Kyle H
> 
> On Mon, Dec 19, 2016 at 3:22 AM, Andy Green  wrote:
> > Hi -
> > 
> > I have a situation coming up that is similar to a client cert being
> > held on a secure key store, like a key vault.
> > 
> > We need to be able to perform TLS communication with a remote
> > server
> > using the key, but without giving the key to OpenSSL.
> > 
> > The "other side" of the "key vault" is smart, and we can run code
> > there, and communicate with it.  So we need to basically proxy
> > OpenSSL
> > operations on the "other side".
> > 
> > I guess this is nothing new under the sun... what's the general
> > approach to integrating this to OpenSSL?
> > 
> > Thanks for any advice.
> > 
> > -Andy
> > --
> > openssl-users mailing list
> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-us
> > ers
> > 
> 
> 
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Setting tlsext_hb_pending in OpenSSL 1.1.x

[Salz, Rich]

> Basically, the SSL structure used to contain tlsext_hb_pending variable. After
> looking up, I found out there is now a function to get the value of 'pending'.
> What I need is to set the value. How can I do that now with 1.1.x?

It seems that when the structures were made opaque, we didn't realize that a 
settor was needed.

Please open an issue for this.  Or better, a pull request that also includes 
the doc update :)  We can then much more easily put it in 1.1.0 and master. 
Missing acessors/settors are bugfixes.

As for checking which version of openssl, see OPENSSL_VERSION #define.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] General approach for keeping a client cert from openssl

[Kyle Hamilton]

You cannot keep the certificate from OpenSSL, as that's the piece that you
share with the remote side.  This contains the public key, and the
information bound to that public key by the CA.

However, you can keep the private key from being seen by OpenSSL.  There
exists what is called an ENGINE interface to offload cryptographic
operations to a container.  Right now,
https://wiki.openssl.org/index.php/Creating_an_OpenSSL_Engine_to_use_indigenous_ECDH_ECDSA_and_HASH_Algorithms
seems to be the best documentation available to explain the process of
creating it.  Obviously, depending on the type of key you're using, you
will probably need to figure out the differences.

-Kyle H

On Mon, Dec 19, 2016 at 3:22 AM, Andy Green  wrote:

> Hi -
>
> I have a situation coming up that is similar to a client cert being
> held on a secure key store, like a key vault.
>
> We need to be able to perform TLS communication with a remote server
> using the key, but without giving the key to OpenSSL.
>
> The "other side" of the "key vault" is smart, and we can run code
> there, and communicate with it.  So we need to basically proxy OpenSSL
> operations on the "other side".
>
> I guess this is nothing new under the sun... what's the general
> approach to integrating this to OpenSSL?
>
> Thanks for any advice.
>
> -Andy
> --
> 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

Re: [openssl-users] Problem with certificate check when it does not match CN

[Viktor Dukhovni]

> On Dec 19, 2016, at 2:12 AM, Brice André  wrote:
> 
> On self-written client side, I use C++ code whose soap part is generated by 
> gsoap. You will find attached the generated code, as well as the wrapper that 
> I wrote and that uses the generated code). I also use openssl (1.0.1j 15 Oct 
> 2014).

OpenSSL 1.0.1j has no built-in name checks.  It only verifies the
validity of the trust chain, and leaves matching of the server name
to the names in the certificate up to the application.  (OpenSSL 1.0.2
added support for built-in name checks, but these still have to be
enabled by the application).  Therefore, your guesses about the
CN vs. subjectAltName wildcards are not pertinent.

The presented certificate chain is fine, and validates with OpenSSL
1.0.1 (which is End-Of-Life in a few days, you really should be using
1.0.2) against the below root CA:

-BEGIN CERTIFICATE-
MIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU
MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFs
IFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
MB4XDTAwMDUzMDEwNDgzOFoXDTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0Ux
FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h
bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9v
dDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTngTlvt
H7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9
uMq/NzgtHj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzX
mk6vBbOmcZSccbNQYArHE504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LX
a0Tkx63ubUFfclpxCDezeWWkWaCUN/cALw3CknLa0Dhy2xSoRcRdKn23tNbE7qzN
E0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3CitlttNCbxWyuHv77+ldU9U0
WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTLVBowCwYD
VR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0
Jvf6xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRU
cnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsx
IjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcN
AQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5gdkeWxQHIzZlj7DYd7usQWxH
YINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKWt9x+Tu5w/Rw5
6wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC
Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEX
c4g/VhsxOBi0cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5a
mnkPIAou1Z5jJh5VkpTYghdae9C8x49OhgQ=
-END CERTIFICATE-

Your Zip file contains no calls to the OpenSSL library, if your
SOAP toolkit is failing to connect to your server, you'll have
to pursue that with whoever supports that toolkit.

-- 
Viktor.

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

[openssl-users] General approach for keeping a client cert from openssl

[Andy Green]

Hi -

I have a situation coming up that is similar to a client cert being
held on a secure key store, like a key vault.

We need to be able to perform TLS communication with a remote server
using the key, but without giving the key to OpenSSL.

The "other side" of the "key vault" is smart, and we can run code
there, and communicate with it.  So we need to basically proxy OpenSSL
operations on the "other side".

I guess this is nothing new under the sun... what's the general
approach to integrating this to OpenSSL?

Thanks for any advice.

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