Re: Cert hot-reloading
On 8/30/2020 20:19, Jordan Brown wrote:
Well, I can restate the problem that I encountered.
We deliver an integrated storage system. Under the covers it is a
modified Solaris running a usual collection of proprietary and
open-source components. We supply an administrative user interface
that, among many other things, lets you manage a list of "trusted"
certificates - typically CA certificates that a program would use to
authenticate its peers. That is, it's the equivalent of Firefox's
Tools / Options / Privacy & Security / Certificates / View
Certificates, and the "Servers" and "Authorities" tabs there, with the
additional tidbit that for each certificate you can control which
services (e.g. LDAP, et cetera) that certificate is trusted for.
When an administrator makes a change to the trusted-certificates list,
we want that change to take effect, system-wide.
The problem is that that means that some number of processes with
active OpenSSL contexts need to drop those contexts and recreate them,
and we don't know which processes those are. Client operations are
typically driven through a library, not a separate daemon, and so
there's no centralized way to know which processes might be TLS
clients. In addition, there's the question of how to *tell* the
process to recreate the context. Simply restarting them may involve
disruption of various sorts.
What we'd like would be for OpenSSL to, on every authentication, stat
the file or directory involved, and if it's changed then wipe the
in-memory cache.
Yes, aspects of this are system-specific, but that's true of many
things. There could easily be an internal API that captures a
current-stage object, and another that answers "is this still the
same". The default implementation could always say "yes".
I'm trying to figure out why you want to replace the context in an
*existing* connection that is currently passing data rather than for new
ones.
For new ones, as I've noted, it already works as you'd likely expect it
to work, at least in my use case, including in multiple threads where
the context is picked up and used for connections in more than one
place. I've had no trouble with this and a perusal of the documentation
(but not the code in depth) suggested it would be safe due to how
OpenSSL does reference counts.
While some of the client connections to the back end in my use case are
"controlled" (an app on a phone, for example, so I could have control
over what happens on the other end and could, for example, send down a
sequence demanding the client close and reconnect) there is also a
general web-style interface so the connecting party could be on any of
the commodity web browsers, over which I have no code control.
Example meta-code:
get_lock(mutex)
if (web_context) { /* If there is an existing context then free it up */
SSL_CTX_free(web_context);
www_context = NULL; /* It is not ok to attempt to use SSL */
}
www_context = SSL_CTX_new(server_method); /* Now get a new context */
(set options, callbacks, verification requirement on certs
presented, DH and ECDH preferences, cert and key, etc)
if NOT (happy with the previous sequence of options, setting key and
cert, etc) {
SSL_CTX_free(web_context);
web_context = NULL;
}
unlock(mutex)
Then in the code that actually accepts a new connection:
get_lock(mutex)
if (web_context) {
ssl_socket = starttls(inbound_socket, www_context, );
check non-null to know it's ok, if it is, store and use it
}
unlock(mutex)
("starttls" does an SSL_new on the context passed, does the SSL_set_fd
and SSL_accept, etc, handles any errors generated from that and if
everything is ok returns the SSL structure)
I've had no trouble with this for a good long time; if there are
existing connections they continue to run on the previous www_context
until they close. New connections come off the new one. You just have
to run a mutex to make sure that you don't try to create a new
connection while the "re-keying" is "in process".
--
Karl Denninger
k...@denninger.net <mailto:k...@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Cert hot-reloading
On 8/30/2020 19:28, Viktor Dukhovni wrote: On Sun, Aug 30, 2020 at 05:45:41PM -0500, David Arnold wrote: If you prefer this mailing list over github issues, I still want to ask for comments on: Certificate hot-reloading #12753 <https://github.com/openssl/openssl/issues/12753> Specifically, my impression is that this topic has died down a bit and from the linked mailing list threads, in my eye, no concrete conclusion was drawn. I'm not sure how to rank this motion in the context of OpenSSL development, but I guess OpenSSL is used to producing ripple effects, so the man-hour argument might be a genuinely valid one. Please inform my research about this issue with your comments! This is a worthwhile topic. It has a few interesting aspects: 1. Automatic key+cert reloads upon updates of key+cert chain PEM files. This can be tricky when processes start privileged, load the certs and then drop privs, and are no longer able to reopen the key + cert chain file. - Here, for POSIX systems I'd go with an approach where it is the containing directory that is restricted to root or similar, and the actual cert files are group and or world readable. The process can then keep the directory file descriptor open, and then openat(2) to periodically check the cert file, reloading when the metadata changes. - With non-POSIX systems, or applications that don't drop privs, the openat(2) is not needed, and one just checks the cert chain periodically. - Another option is to use passphrase-protected keys, and load the secret passphrase at process start from a separate read-protected file, while the actual private key + cert chain file is world readable, with the access control via protecting the passphrase file. - In all cases, it is important to keep both the private key and the cert in the same file, and open it just once to read both, avoiding races in which the key and cert are read in a way that results in one or the other being stale. 2. Having somehow obtained a new key + cert chain, one now wants to non-disruptively apply them to running servers. Here there are two potential approaches: - Hot plug a new pointer into an existing SSL_CTX structure. While the update itself could be made atomic, the readers of such pointers might read them more than once to separately extract the key and the cert chain, without checking that they're using the same pointer for both operations. This is bound to be fragile, though not necessarily impossible. - Build a new SSL_CTX, and use it to accept *new* connections, while existing connections use whatever SSL_CTX they started with. I believe this can work well, because "SSL" handles increment the reference count of the associated SSL_CTX when they're created, and decrement it when destroyed. So when you create a replacement SSL_CTX, you can just SSL_CTX_free() the old, and it will only actually be deleted when the last SSL connection tied to that SSL_CTX is destroyed. It is true that typical SSL_CTX construction is modestly expensive (loading CA stores and the like) but some of that could be handled by sharing and reference-counting the stores. So my preferred approach would be to create a new SSL_CTX, and get new connections using that. Now in a multi-threaded server, it could be a bit tricky to ensure that the SSL_CTX_free() does not happen before all threads reading the pointer to the latest SSL_CTX see the new pointer installed. Something equivalent to RCU may be needed to ensure that the free only happens after the new pointer is visible in all threads. Designs addressing various parts of this would be cool, provided they're well thought out, and not just single-use-case quick hacks. This works now; I use it with an application that checks in with a license server and can grab a new cert. OpenSSL appears to have no problem with setting up a new SSL_CTX and using it for new connections; the old ones continue onward until they terminate, and new ones are fine as well. This appears to be be ok with the current code; I've yet to have it blow up in my face although at present the certs in question are reasonably long-lived. Whether it's robust enough to handle very short-term certificates I do not know. -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature
Re: Goodbye
On 7/3/2020 13:45, Jordan Brown wrote: > On 7/3/2020 6:03 AM, Marc Roos wrote: >> Also hypocrite of Akamai, looking at the composition of the executive team. > > I think it's pretty clear that Rich was speaking as himself, not as a > representative of Akamai. > Sorry, that's not how it works. You post and reference a corporate email address, which he did, /you just took the action under the banner of the company./ Akamai is entirely _*and justifiably*_ exposed to being "canceled" on that basis. -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature
Re: Questions about signing an intermediate CA
On 2/12/2020 12:59, Michael Leone wrote: > > > On Wed, Feb 12, 2020 at 1:24 PM Karl Denninger <mailto:k...@denninger.net>> wrote: > > On 2/12/2020 11:32, Michael Leone wrote: >> So we are mostly a MS Windows shop. But I use a Linux openssl as >> my root CA. What I am planning on doing, is creating a Windows >> intermediate CA, and using that to sign all my internal requests. >> But before I do that, I have a couple of questions. >> >> I have the steps to install the certificate services in AD, and >> create an intermediate CA request. What I'm wondering is, do I >> sign that cert differently than any normal cert? I don't see why >> I would. I mean, the request should specify that it wants to be a >> CA, and so I should just be able to >> >> openssl ca -in -out >> >> and maybe the -extfile, to specify SANs. >> >> Am I correct in thinking that? I see many, many openssl examples, >> but they're all for creating an intermediate CA using openssl, >> which I'm not doing. And the rest of the examples seem to be how >> to sign using the resulting intermediate CA cert itself, which >> again, is not what I will be doing . >> >> Any pointers appreciated. Thanks! >> > You have to sign the intermediate with the root in order to > maintain the chain of custody and certification. > > > Well, yes. Sorry if that wasn't clear. Yes, the only CA I have is the > root, so that is what I will be signing with. So what I am asking, is > the signing command different for an intermediate CA than for a > regular (I guess the term is "End Entity") certificate? > No, other than specifying the signing certificate to be used (e.g. the root CA) -- the certificate ITSELF, however, is different than an end-entity certificate. The EKU constraints should be correct (e.g. chain length, etc) and "CA:true" has to be set for it (and must NOT be set on an end-entity certificate.) I have no clue what Microsoft does or doesn't do with their certificate management stuff; I use OpenSSL to do it. -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature
Re: Questions about signing an intermediate CA
On 2/12/2020 11:32, Michael Leone wrote: > So we are mostly a MS Windows shop. But I use a Linux openssl as my > root CA. What I am planning on doing, is creating a Windows > intermediate CA, and using that to sign all my internal requests. But > before I do that, I have a couple of questions. > > I have the steps to install the certificate services in AD, and create > an intermediate CA request. What I'm wondering is, do I sign that cert > differently than any normal cert? I don't see why I would. I mean, the > request should specify that it wants to be a CA, and so I should just > be able to > > openssl ca -in -out > > and maybe the -extfile, to specify SANs. > > Am I correct in thinking that? I see many, many openssl examples, but > they're all for creating an intermediate CA using openssl, which I'm > not doing. And the rest of the examples seem to be how to sign using > the resulting intermediate CA cert itself, which again, is not what I > will be doing . > > Any pointers appreciated. Thanks! > You have to sign the intermediate with the root in order to maintain the chain of custody and certification. That is, the chain of trust is Root->Intermediate->..-> End Entity You can (of course) branch more than once; it is common to have more than one Intermediate, for example, for different types of entity for which different parts of an organization have responsibility, and you can sub-delegate intermediates as well. Just note that when an end entity certificate is validated the entire chain back to the root of trust (which is self-signed) has to be able to be verified. -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature
Re: Can a linux service work as both TLS client and server?
On 11/15/2019 17:27, Kristen Webb wrote: > In the future, I will not have an initial TCP 1/0 packet (clue) to > process. > So I have no way to decide if my forked/spawned process should SSL_connect > or SSL_accept. > > For example, I cannot see how this can be done with Apple's network > framework > (at least not yet). It appears to be so high level as to not allow me > to process a TCP packet within a TLS style connection. I realize that > this is not > an openssl issue. And I do have things working today with Apples security > framework and openssl (with that extra TCP packet clue in place). I > am more familiar > with openssl and I'm trying to code everything there first. Also my > entire application > runs on linux so I am able to test all the combinations easily from > there. And I'll > need it to work with Apple's networking in the future as their > security APIs go away. > > Thank you for bearing with me so far! > I don't quite understand what you're attempting to do, or why. I assume (since you're sending the initial packet) that the "thing" connecting to the OpenSSL end is under your control (it's your code.) If so, why do you care which "way" the listening end comes up? By convention if you are doing a listen() on an a socket then you're a server. You don't have to be from an SSL perspective, but from a socket perspective you absolutely are. So why do you want to select "which way" you do this on the TLS/SSL end? Is it a function of which end has a certificate (or whether both do) and which one(s) you care to verify (or not)? If so that can be dealt with through options and who checks what, rather than what you're doing now. I'm trying to understand the workflow you are attempting to implement, and why, because I suspect you may be going about this the hard way. -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature
Re: To get end point's IP address
On 5/21/2019 4:53 AM, Chethan Kumar wrote: Thanks for the information. I researched more and found that tlsext_hostname member variable in SSL structure can be used to to get host name. If applications set this using SSL_set_tlsext_host_name(), is it correct to print hostname/IP in tlsext_hostname. Can I use this one to set hostname/Ip address.? Can applications acting as both server and client set this? Thanks in advance, Chethan Kumar Why do you want the specific IP address? If the other end is behind a NAT device or similar (or a full-blown proxy) then that address is not meaningful in the context of actual identification as to the source of the communication. Better, if it is necessary to know who you're talking to, is for the client to present a certificate which the server can then verify as to validity and provenance; the client, of course, by definition has same capability against the server so it can verify that the server it thinks it is talking to is actually the one it's communicating with. -- -- Karl Denninger /The Market-Ticker/ S/MIME Email accepted and preferred smime.p7s Description: S/MIME Cryptographic Signature
Re: Crashes when generating certificate
On 5/14/2019 09:48, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of >> Karl Denninger >> Sent: Monday, May 13, 2019 16:32 >> On 5/13/2019 16:44, Christopher R wrote: >>> All I want is whatever remnants of that incorrect certificate removed, >>> where ever they are, and a correct certificate created. >> Not sure what you have left, but probably in the certs directory. > I can't think of what remnant of the old certificate would be there, except > the certificate itself, in whatever the configuration file specifies for the > new_certs_dir. And I've never seen that cause this problem. There's a directory (by default "newcerts" but can be changed in the config file) that has a copy of the certs that OpenSSL generates. If there's a collision in there (which could happen if the serial number is reused) "bad things" could happen. I've not looked at the code to see if that would cause a bomb-out but the risk with playing in the database file, although it's just a flat file, and/or the serial number index is that you can wind up with conflicts. The "ca" function in openssl lacks the sort of robustness and "don't do that" sort of protections that one would expect in a "production" setting. That's not say it can't be used that way but quite a bit of care is required to do so successfully, and toying around in the database structure by hand is rather removed from that degree of care. -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature
Re: Crashes when generating certificate
On 5/13/2019 16:44, Christopher R wrote: > So I'm trying to create a certificate for a new user on my domain. > Created the certificate... got everything set up... went to use it and > the email is completely wrong. Oops. Missed it when I updated the > configuration file, and,unfortunately, its necessary, because login > depends on the email associated with the certificate. > > Ok, take 2. Delete everything. Delete the certificates, the request, > all of it for that new user. Correct the config file and try again. > Gets to the end and throws TXT_DB Error number 2. Look it up and its > because a certificate with that common name is already in the > database. Someone recommends editing that certificate out of the > database, so I pull up the index file, find the line for the incorrect > certificate, and delete it. > > Cool. Take 3. Generates the key and the request. Try generating the > certificate... it asks for a password and then does... nothing. Kicks > directly to command prompt. No error. No lines of text. No > questions. Nothing created. Password->command prompt. What is going > on here and how do I fix this? > > All I want is whatever remnants of that incorrect certificate removed, > where ever they are, and a correct certificate created. Not sure what you have left, but probably in the certs directory. In the future REVOKE the one with the bad information, and you can then create a new one under the same common name. Since the index file is a flat file you can edit it, but you also have to make sure the other places it references are also updated or the software can get confused. The better choice when an error is made is to revoke the bad cert, which prevents this from happen. -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature
Re: Internal IP Exposed
On 3/24/2019 19:33, Abdul Qoyyuum wrote: > Hi all, > > New to the mailing list and a complete newbie to openssl and the > likes. There's a ticket by a client that I'm new at and he claims that > there's a security problem with the openssl command to his servers. > > Internal IP exposed after running a openssl (version 1.1.0j) connect > command: > > |openssl s_client -connect 103.XX.XXX.XX:10443 -quiet | > > Where 103.XX.XXX.XX is a Public IP. And after it shows the > certificates, typed the following: > > |GET /images HTTP/1.0 | > > And hit enter twice, the following gets displayed: > > |HTTP/1.0 301 Moved Permanently Date: Mon, 25 Mar 2019 00:10:13 GMT > Server: -x Location: https://10.240.123.1:10443/images/ > Connection: close Content-Type: text/html; charset=utf-8 > X-Frame-Options: SAMEORIGIN Content-Security-Policy: frame-ancestors > 'self' X-XSS-Protection: 1; mode=block X-Content-Type-Options: nosniff > Strict-Transport-Security: max-age=28800 "-//IETF//DTD HTML 2.0//EN"> 301 Moved > Permanently Moved Permanently The > document has moved HREF="https://10.240.123.1:10443/images/;>here. > read:errno=0 | > > The 10.240.123.1 is an internal IP and it is exposed by this little > method. Although not shown when using |curl -kv -O| command. > > Is there a way to cover up the "Location" or at least the internal IP > from being exposed? Thanks. > > Sorry if this isn't clear or if this is the wrong place to ask this. > OpenSSL is not involved in that in any way so the fix and issue is not there. I am assuming that the original connection is to a "tunnel" on the internal/external gateway. That is, connect to and the gateway "twists" that to the internal address on port 443, which is the usual HTTPS port (this assumption is due to that looking like an HTTPS server from what it returns.) This is a very common firewall/gateway function. The issue is that OpenSSL just created and maintained the SSL connection and data transport. The offending information isn't emitted by OpenSSL; it's emitted by the remote server code itself and OpenSSL simply transports it from one end to the other, encrypted. It thus must (and does) transport exactly, byte-by-byte, whatever it gets (in both directions.) The server code on the remote end could be programmed to not issue the header and body text, but if it generates a 301 the HTML header "Location:" MUST be returned with the new location by the HTML specifications so the application that connected (typically a browser) can issue a new request to the correct, redirected place. However it doesn't have to return an IP number and most servers do not because there frequently is more than one host and/or domain on a given IP number -- it could and should instead return a domain name (e.g. "https://www.example.com/images;) -- but that header has to be there. The body text actually does not; it can be void and it's ok (that's not used by browsers, but is useful for humans if/when troubleshooting.) The issue is LIKELY that the host in question doesn't have a reverse IP mapped for itself but that's web server and OS dependent. It may also be that the hostname is not defined in the server's configuration file. Without knowing what the web server in question is all I can do there is guess as to exactly what is missing, but in any event the issue is in the web server application configuration and not OpenSSL. -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [openssl-users] Close TCP socket after SSL_clear()?
On 1/10/2019 17:07, Charles Mills wrote:
>
> On Windows, for a new session, I am issuing a Windows accept()
> followed by SSL_new(), SSL_set_fd() and so forth.
>
>
>
> When the session sees some sort of an abnormal receive condition, I am
> doing
>
>
>
> int *retCode* = SSL_get_shutdown(sessionSSL);
>
> if ( *retCode* & SSL_RECEIVED_SHUTDOWN )
>
> {
>
> SSL_shutdown(sessionSSL);
>
> }
>
> else
>
> {
>
> SSL_clear(sessionSSL);
>
> }
>
>
>
> Questions:
>
>
>
> 1. Do I also need to do a closesocket() (equivalent to UNIX
> close()) on the Windows socket?
>
> 2. Does anyone want to critique the above logic in any other way?
>
>
>
> The code basically “works” but I see evidence that a Windows TCP
> session is still open following an SSL error.
>
>
>
> Thanks,
>
>
>
> /Charles Mills/
>
>
Are you sure you want to use SSL_clear() in the first place? It retains
the session's settings which is only useful if the *exact* same peer is
going to reconnect on the same SSL object. If a *different* peer
connects there's a decent shot that the connection will fail.
You also likely want to call SSL_shutdown(connection) again IF the first
call returns zero; the first one sends a notification and if the other
end hasn't closed yet returns zero. The second waits for a termination,
either normal notification or abnormal, from the other end.
if (!SSL_shutdown(connection)) {
SSL_shutdown(connection)
}
The underlying handle is still open at the OS level after this, so on
Unix anyway you want to notify the OS that the socket is invalid for
further I/O and then close it.
Code snippet (took_error is a flag that says "this connection is no
longer needed", it's could be either an error in the higher level code
or a "we're all done, let this connection go" indication):
if (slave_socket[x].took_error) {
slave_socket[x].connected = 0; /* Connection is void */
if (slave_socket[x].ssl_fd != NULL) { /* If there's
a valid SSL connection */
if (!SSL_shutdown(slave_socket[x].ssl_fd)) {
SSL_shutdown(slave_socket[x].ssl_fd);
}
SSL_free(slave_socket[x].ssl_fd);
slave_socket[x].ssl = 0; /* We are not in SSL
mode */
}
shutdown(slave_socket[x].fd, SHUT_RDWR);
close(slave_socket[x].fd);
. Clean up the rest of the things you need to do
when the connection ends
Since the next connection may come from a different peer I do not use
SSL_clear but rather SSL_free.
The call to shutdown() tells the OS to send any data queued on the
socket, wait for an ACK and then send FIN.
--
Karl Denninger
k...@denninger.net <mailto:k...@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
smime.p7s
Description: S/MIME Cryptographic Signature
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Programmatically check private key and public key cert?
On 1/11/2018 09:28, pratyush parimal wrote: > Hi, > > Hope everyone is having a good new year so far! > > I'm trying to find a way to make sure that a > private-key/public-key-cert pair I'm given, will absolutely work when > I stick them into my SSL_CTX* object and try to use that for ssl. > Short of trying to simulate a test ssl connection over localhost for > testing them out, is there a way to ensure that? > > After googling, it seems that I may be able to verify that by > comparing the modulus from the key and the cert. Does anyone know if > that's sufficient, and how to do it programmatically? If you call SSL_CTX_check_private_key() on your context it will return "0" if the private key and certificate you have loaded do not match (and thus won't work.) If you get a "1" back then provided you have a set of ciphers declared (or the defaults) that are compatible on both ends so the code can negotiate a cipher set then it should work. There is no guaranteed way to know if a connection will work from some other piece of code you don't control, however, because it's entirely possible for the other end to try to insist on (or only be able to support) a protocol you have disallowed (e.g. SSLv3) or for there to be no intersection between the cipher sets allowed by both sides and the certificate and key constraints (never mind certificate validation, if you are checking it.) > > I was also wondering if I should just try to perform an > encrypt-decrypt sequence using the pair I have, and use the success of > that as confirmation that my ssl connection will work later, as far as > the certs are concerned. Would that be the right way to go about it? > IMHO see above. -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Confirmation of what I believe to be true from docs and observation
On 1/10/2018 14:07, Benjamin Kaduk wrote:
> On 01/10/2018 08:41 AM, Karl Denninger wrote:
>> We start with a context that I load a dhparam file to (so I can take a
>> DH connection) along with an edh curve, then set an acceptable cipher
>> list for it to use.
>>
> Why not just use AUTO_DH (the only option for 1.1.0, IIRC)?
That's a reasonable change (and I'll go ahead and make it); the dhparam
was only there in the first place for those browsers and such that can't
negotiate EC (which my cipher selection set prefers.)
>> Assume I next manually load both the CA store (using
>> X509_STORE_add_cert as many times as necessary to load the
>> intermediate components and the root of trust) and then load the
>> cert/key pair (using SSL_CTX_use_certificate/SSL_CTX_use_PrivateKey)
>>
>> I then create some number of SSLs from that context to perform
>> communication with and all is well.
>>
>> Now I want to rekey that context for some reason. It appears that
>> while I can add things to
>>
> Why do you need to rekey the context as opposed to making a new one?
I could make a new one (or more-specifically, destroy the existing one
and re-initialize it), but that is more-complicated as the application
in question is multi-threaded -- and it's not at all clear from the
documentation if I destroy a context that has SSLs that have been
generated from it will cause "bad things" to happen (like a deference on
a freed object!)
The reason I may want to rekey is that the cert/key pair used for that
context may have changed. The user's certificate may have expired for
example (or been revoked) and I wish to reload it (and the matching key)
without having to shut down the software and restart it.
> In general, making configuration changes to an SSL_CTX after it has been
> used to generate SSL objects is a risky proposition -- the locking model
> does not really account for doing synchronization properly, and there
> might be some latent race conditions. In practice, some operations are
> currently safe, but there is no authoritative list of which ones, and at
> least my personal recommendation is to not try to rely on it.
Assuming that there are SSL objects that are in use and I destroy and
re-generate the CTX from which it was generated, is *THAT* safe? Or do
I need to flag all the in-use descendants and wait for them to be closed
(or force them closed and release them) before I can safely destroy the
context?
>> the CA chain trying to load the same component that is already in
>> there returns a failure (somewhat-expected; that is, it does not
>> overwrite but rather adds, and if you try to add what's already there
>> you get an error back) and there's no call to CLEAR the certificate
>> validation chain -- if I want to *replace* the validation chain I have
>> to destroy the context and initialize a new one from scratch.
>>
> N.B. that the X509_STORE_add_cert behavior when presented with a
> duplicate certificate changed in commit
> c0452248ea1a59a41023a4765ef7d9825e80a62b (from returning an error to
> doing nothing and returning success); this will be in 1.1.1.
>
> As to the desired behavior, there does not seem to be an API to remove
> an entry from an X509_STORE. With the above caveat about thread-safety
> in mind, couldn't you just make a call to SSL_CTX_set{1}_cert_store() to
> replace the X509_STORE without tearing down the whole SSL_CTX?
Yeah, I didn't see one either. I'm not particularly concerned about the
verification chain being able to be modified while "in-use"; that ought
not happen except in an extreme circumstance (e.g. the intermediate
cert's key is compromised and thus both it and the cert have to be
regenerated and re-distributed.) If it DOES happen when the end-entity
cert and key are reloaded (as they've been signed from the new
intermediate) they'll fail to validate against the old chain and the
user will get plenty of notice that there's trouble.
>> It appears, however, that I *can* load over the top of a certificate
>> and private key of the same type and that's acceptable. In other
>> words, if I have an RSA key/cert pair in the context and I load
>> another one, the first one is replaced. This *looks* to be working ok
>> as far as I can tell and it doesn't appear to leak memory doing that
>> but it's not explicitly stated that this is considered acceptable
>> (rather than destroying and re-creating the context.)
>>
> The leaf certificate and private key are stored as arrays (for different
> types of certificates) of pointers in the associated CERT structure, and
> the "set" routines do not currently check for and error out if there is
> already one set.
Yes, but do they replace the pointer and, if they do, do the
[openssl-users] Confirmation of what I believe to be true from docs and observation
We start with a context that I load a dhparam file to (so I can take a DH connection) along with an edh curve, then set an acceptable cipher list for it to use. Assume I next manually load both the CA store (using X509_STORE_add_cert as many times as necessary to load the intermediate components and the root of trust) and then load the cert/key pair (using SSL_CTX_use_certificate/SSL_CTX_use_PrivateKey) I then create some number of SSLs from that context to perform communication with and all is well. Now I want to rekey that context for some reason. It appears that while I can add things to the CA chain trying to load the same component that is already in there returns a failure (somewhat-expected; that is, it does not overwrite but rather adds, and if you try to add what's already there you get an error back) and there's no call to CLEAR the certificate validation chain -- if I want to *replace* the validation chain I have to destroy the context and initialize a new one from scratch. It appears, however, that I *can* load over the top of a certificate and private key of the same type and that's acceptable. In other words, if I have an RSA key/cert pair in the context and I load another one, the first one is replaced. This *looks* to be working ok as far as I can tell and it doesn't appear to leak memory doing that but it's not explicitly stated that this is considered acceptable (rather than destroying and re-creating the context.) Is my understanding correct? -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Unclear docs -- request clarification on X509_STORE_add_cert
On 1/2/2018 19:36, Dave Coombs wrote: >> The observation is correct, but the conclusion is wrong. >> The object is reference counted, and X509_free() is needed >> to avoid a leak (when the store is freed along with the >> context). > My apologies -- I assumed based on its name that X509_OBJECT_up_ref_count was > upping the refcount on the internal X509_OBJECT, which had taken over the > X509*, which led to my conclusion that freeing the X509_STORE frees the X509 > too. However, you're right, it ups the refcount on the underlying X509, and > so the caller *should* free the underlying object when finished with it. > > I've now confirmed with a quick test program and valgrind. > > Oops, > -Dave Thanks. -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Unclear docs -- request clarification on X509_STORE_add_cert
Assume the following code snippet:
const unsigned char a_cert = {... }; (A DER certificate we wish to
load into the context's chain storage)
int size_a_cert = sizeof(a_cert);
const unsigned char *cp;
X509 *cc_cert;
X509_STORE *cc = SSL_CTX_get_cert_store(a_context);
if (cc == NULL) {
panic ("Cannot get chain; fail");
}
cp = a_cert;
cc_cert = d2i_X509(NULL, , size_a_cert);
if (cc_cert == NULL) {
panic("Cert not valid");
}
if (!X509_STORE_add_cert(cc, cc_cert)) { /* Push the cert into
the chain store */
panic ("Cannot add required chain certificate");
}
/* X509_free(cc_cert); */
The question is the last line and whether it should be there
(uncommented) -- does the X509_STORE_add_cert call load the *reference*
or does it load the *data* (allocating whatever it needs internally to
do so)? In other words do I need to keep that X509 structure around
that got allocated by the d2i_X509 call or do I free it after I've
pushed it into the store?
The docs are silent on this as far as I can tell but some example code
I've seen floating around doesn't free it.
--
Karl Denninger
k...@denninger.net <mailto:k...@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
smime.p7s
Description: S/MIME Cryptographic Signature
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Question as to best options....
On 12/28/2017 18:31, Salz, Rich via openssl-users wrote: > > It is hard to follow this thread with all the indenting. > > > > > If I take a PEM-encoded RSA private key file and convert it to > binary (using b64decode) what I get is not the same thing as I get > from "openssl rsa -inform pem -in key -outform der -out key.der". > > How do you convert it? Did you strip off the ---BEGIN and END tags? > Then it absolutely should have been the same thing. > Yes, I certainly did. And it's not the same thing. Proof: root@Test-MCP:/usr/local/etc/HD-MCP/ssl/x # diff key.pem test.key 0a1 > -BEGIN PRIVATE KEY- 26a28 > -END PRIVATE KEY- root@Test-MCP:/usr/local/etc/HD-MCP/ssl/x # ls -al total 16 drwxr-xr-x 2 root wheel 512 Dec 28 18:36 . drwx-- 3 hdmcp wheel 512 Dec 28 18:33 .. -rw--- 1 root wheel 1654 Dec 28 18:33 key.pem -rw--- 1 root wheel 1708 Dec 28 18:35 test.key Only difference is the barrier lines in the test.key file (which have to be there for openssl or it throws up.) Now we run: root@Test-MCP:/usr/local/etc/HD-MCP/ssl/x # openssl rsa -inform pem -in test.key -outform der -out key.der writing RSA key root@Test-MCP:/usr/local/etc/HD-MCP/ssl/x # b64decode -r key.pem > key.bin root@Test-MCP:/usr/local/etc/HD-MCP/ssl/x # ls -la total 24 drwxr-xr-x 2 root wheel 512 Dec 28 18:37 . drwx-- 3 hdmcp wheel 512 Dec 28 18:33 .. -rw-r--r-- 1 root wheel 1219 Dec 28 18:37 key.bin -rw-r--r-- 1 root wheel 1193 Dec 28 18:37 key.der -rw--- 1 root wheel 1654 Dec 28 18:33 key.pem -rw--- 1 root wheel 1708 Dec 28 18:35 test.key root@Test-MCP:/usr/local/etc/HD-MCP/ssl/x # Those output files (key.bin and key.der) are not the same -- they're different within the first few bytes on examination with od -t x1, not just on length (e.g. trash at the end) If I load key.der into a binary buffer and run d2i_AutoPrivateKey against it I get a valid EVP_PKEY buffer back and no error. I'll chase this down further, but I think the easiest way may be to just run DER files, since those work... :-) > An internal structure, such as an RSA object, can be converted to DER > using d2i_RSA. DER is useful because it is a “flat” format, whereas > the internal object is useful in the C code. Make sense? DER files > are useful if you already know what the filetype is. The d2i_ and > i2d_ functions convert between internal (C structures, with pointers > etc) to DER encoding. They basically work on buffers, only. > > PEM files are base64 encoded DER, with BEGIN and END tags that specify > what the middle-part is. It is useful because it is human readable. > Also the PEM_read_ functions will check what is expected to what > the file says it is. > > Most objects have PEM_read and PEM_write functions as well. They are > not necessarily obvious from scanning the header files, because they > are declared and implemented as macro’s, as it’s common code with just > a pointer to an internal description of what the ASN1/DER looks like. > > The documentation on the master branch does a much better, and more > complete, job of explaining this. > > The function I think you want is PEM_read_PrivateKey. > I'll look in there; my assumption was that I could trivially convert a PEM file into an internal DER representation by stripping the flag lines from the front and rear and then decoding the base64 piece. Thanks; I'll figger it out :-) -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Question as to best options....
On 12/28/2017 16:57, Karl Denninger wrote:
> On 12/28/2017 16:15, Karl Denninger wrote:
>> On 12/26/2017 14:07, Kurt Roeckx wrote:
>>> On Tue, Dec 26, 2017 at 01:42:57PM -0600, Karl Denninger wrote:
>>>> On 12/26/2017 13:14, Salz, Rich via openssl-users wrote:
>>>>> So if you put locks around the SSL_CTX object when it’s used, then you
>>>>> can use the set private key call to update the key; and then all
>>>>> SSL_new objects afterwards will use the new credentials. Does that
>>>>> meet your need?
>>>>>
>>>> Yes, that I already know how to do. The issue is how to get the key
>>>> from a PEM file into a format that I can feed it with set private key.
>>>> There doesn't appear to be a means to "un-file-ify" the set private key
>>>> functions.
>>> You can use the d2i_PrivateKey and i2d_PrivateKey functions to read
>>> and write the file.
>>>
>>>>>> "is there a decent way to convert a PEM or DER private key file into
>>>>> ASN.1" using OpenSSL calls (from a "C" program, not from the command
>>>>> line; we'll assume I have the key and cert files already.)
>>>>>
>>>>> I assume you mean “native C structure” and not ASN1? Because DER is
>>>>> just the ASN1 serialized, and PEM is base64 encoded DER with marker
>>>>> lines. …
>>>>>
>>>>>
>>>>>
>>>> So if I take a PEM private key file, strip the markers, and turn the
>>>> actual key's base64 into binary (assuming an RSA key, so there's no "EC
>>>> parameter" block in front) I now have an "opaque" unsigned character
>>>> array of length "len" (the decoded Base64) which
>>>> SSL_CTX_use_privateKey_ASN1 will accept? (Assuming the key file is
>>>> unencrypted, of course.)
>>>>
>>>> What is the parameter "pk" passed to the call in that instance (it's not
>>>> in the man page)
>>> From the manpage:
>>> SSL_CTX_use_PrivateKey_ASN1() adds the private key of type _pk_
>>>
>>> So you would need to know that it's an RSA or EC key. If you used
>>> d2i_AutoPrivateKey you don't need to know the type and get an
>>> EVP_PKEY.
>>>
>>>
>>> Kurt
>> Not sure what I'm doing wrong here but obviously its something!
>>
>> certtemp = *char
>> certstore = unsigned char* (Both with enough allocated memory to
>> hold the required data, of course)
>> const unsigned char *p;
>>
>> certstore has the Base64 key in it (checked manually, I am reading it
>> properly from the key file with the barrier lines and line feeds
>> omitted.)
>>
>> ...
>>
>> strcpy((char *) certstore, certtemp);
>> p = certstore;
>> key = d2i_AutoPrivateKey(NULL, , strlen(certtemp));
>> if (key == NULL) {
>> ERR_error_string(ERR_get_error(), tmp);
>> >> return(NULL);
>> }
>>
>> ..
>>
>> But I get
>>
>> $4 = 0xbf3f9b90 "error:0D0680A8:asn1 encoding
>> routines:ASN1_CHECK_TLEN:wrong tag"
>> in tmp and a NULL key return from d2i_AutoPrivateKey at the ">>"
>> breakpoint.
>>
>> If I convert the base64 to binary first -- using the Base64 routine
>> in OpenSSL (which I know I've coded correctly as the code in question
>> uses it elsewhere to decode a MIME attachment) and pass a binary
>> buffer and the length of that buffer (instead of a base64 buffer and
>> its length) I still get NULL back for the EVP_PKEY structure and the
>> same error text in tmp.
>>
>> If I load that same key file with (having put the path to the key
>> file in tmp) with:
>>
>> if (SSL_CTX_use_PrivateKey_file(www_context, tmp, SSL_FILETYPE_PEM) <
>> 0) {.
>>
>> It loads and works.
>>
>> What's even MORE odd is that if I do this with the SAME key data I
>> just loaded in base64 (knowing it's an RSA key):
>>
>> len = (strlen(certtemp) * 3) / 4 +1;
>> cbin = decode_base64(certtemp, strlen(certtemp));
>> if (SSL_CTX_use_PrivateKey_ASN1(EVP_PKEY_RSA, www_context,
>> cbin, len)) {
>> ERR_error_string(ERR_get_error(), tmp);
>> return(NULL);
>> }
>>
>> THAT loads (the use_PrivateKey_ASN1 call returns zero -- and thus
>> obviously likes what I
Re: [openssl-users] Question as to best options....
On 12/28/2017 16:15, Karl Denninger wrote:
> On 12/26/2017 14:07, Kurt Roeckx wrote:
>> On Tue, Dec 26, 2017 at 01:42:57PM -0600, Karl Denninger wrote:
>>> On 12/26/2017 13:14, Salz, Rich via openssl-users wrote:
>>>> So if you put locks around the SSL_CTX object when it’s used, then you
>>>> can use the set private key call to update the key; and then all
>>>> SSL_new objects afterwards will use the new credentials. Does that
>>>> meet your need?
>>>>
>>> Yes, that I already know how to do. The issue is how to get the key
>>> from a PEM file into a format that I can feed it with set private key.
>>> There doesn't appear to be a means to "un-file-ify" the set private key
>>> functions.
>> You can use the d2i_PrivateKey and i2d_PrivateKey functions to read
>> and write the file.
>>
>>>>> "is there a decent way to convert a PEM or DER private key file into
>>>> ASN.1" using OpenSSL calls (from a "C" program, not from the command
>>>> line; we'll assume I have the key and cert files already.)
>>>>
>>>> I assume you mean “native C structure” and not ASN1? Because DER is
>>>> just the ASN1 serialized, and PEM is base64 encoded DER with marker
>>>> lines. …
>>>>
>>>>
>>>>
>>> So if I take a PEM private key file, strip the markers, and turn the
>>> actual key's base64 into binary (assuming an RSA key, so there's no "EC
>>> parameter" block in front) I now have an "opaque" unsigned character
>>> array of length "len" (the decoded Base64) which
>>> SSL_CTX_use_privateKey_ASN1 will accept? (Assuming the key file is
>>> unencrypted, of course.)
>>>
>>> What is the parameter "pk" passed to the call in that instance (it's not
>>> in the man page)
>> From the manpage:
>> SSL_CTX_use_PrivateKey_ASN1() adds the private key of type _pk_
>>
>> So you would need to know that it's an RSA or EC key. If you used
>> d2i_AutoPrivateKey you don't need to know the type and get an
>> EVP_PKEY.
>>
>>
>> Kurt
> Not sure what I'm doing wrong here but obviously its something!
>
> certtemp = *char
> certstore = unsigned char* (Both with enough allocated memory to hold
> the required data, of course)
> const unsigned char *p;
>
> certstore has the Base64 key in it (checked manually, I am reading it
> properly from the key file with the barrier lines and line feeds omitted.)
>
> ...
>
> strcpy((char *) certstore, certtemp);
> p = certstore;
> key = d2i_AutoPrivateKey(NULL, , strlen(certtemp));
> if (key == NULL) {
> ERR_error_string(ERR_get_error(), tmp);
> >> return(NULL);
> }
>
> ..
>
> But I get
>
> $4 = 0xbf3f9b90 "error:0D0680A8:asn1 encoding
> routines:ASN1_CHECK_TLEN:wrong tag"
> in tmp and a NULL key return from d2i_AutoPrivateKey at the ">>"
> breakpoint.
>
> If I convert the base64 to binary first -- using the Base64 routine in
> OpenSSL (which I know I've coded correctly as the code in question
> uses it elsewhere to decode a MIME attachment) and pass a binary
> buffer and the length of that buffer (instead of a base64 buffer and
> its length) I still get NULL back for the EVP_PKEY structure and the
> same error text in tmp.
>
> If I load that same key file with (having put the path to the key file
> in tmp) with:
>
> if (SSL_CTX_use_PrivateKey_file(www_context, tmp, SSL_FILETYPE_PEM) <
> 0) {.
>
> It loads and works.
>
> What's even MORE odd is that if I do this with the SAME key data I
> just loaded in base64 (knowing it's an RSA key):
>
> len = (strlen(certtemp) * 3) / 4 +1;
> cbin = decode_base64(certtemp, strlen(certtemp));
> if (SSL_CTX_use_PrivateKey_ASN1(EVP_PKEY_RSA, www_context,
> cbin, len)) {
> ERR_error_string(ERR_get_error(), tmp);
> return(NULL);
> }
>
> THAT loads (the use_PrivateKey_ASN1 call returns zero -- and thus
> obviously likes what I passed it)
>
> There's probably something obvious I'm missing on what I'm doing wrong
> with the d2i call -- any quick hit pointers welcome
>
> --
> Karl Denninger
> k...@denninger.net <mailto:k...@denninger.net>
> /The Market Ticker/
> /[S/MIME encrypted email preferred]/
>
>
Ok, never mind, it appears to take the key but then when I check for
coherence between the key and certificate it says they don't match.
so apparently it does NOT like the key load in ASN1, even though it
doesn't complain about it when I call the "use" function.
H
--
Karl Denninger
k...@denninger.net <mailto:k...@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
smime.p7s
Description: S/MIME Cryptographic Signature
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Question as to best options....
On 12/26/2017 14:07, Kurt Roeckx wrote:
> On Tue, Dec 26, 2017 at 01:42:57PM -0600, Karl Denninger wrote:
>> On 12/26/2017 13:14, Salz, Rich via openssl-users wrote:
>>> So if you put locks around the SSL_CTX object when it’s used, then you
>>> can use the set private key call to update the key; and then all
>>> SSL_new objects afterwards will use the new credentials. Does that
>>> meet your need?
>>>
>> Yes, that I already know how to do. The issue is how to get the key
>> from a PEM file into a format that I can feed it with set private key.
>> There doesn't appear to be a means to "un-file-ify" the set private key
>> functions.
> You can use the d2i_PrivateKey and i2d_PrivateKey functions to read
> and write the file.
>
>>>> "is there a decent way to convert a PEM or DER private key file into
>>> ASN.1" using OpenSSL calls (from a "C" program, not from the command
>>> line; we'll assume I have the key and cert files already.)
>>>
>>> I assume you mean “native C structure” and not ASN1? Because DER is
>>> just the ASN1 serialized, and PEM is base64 encoded DER with marker
>>> lines. …
>>>
>>>
>>>
>> So if I take a PEM private key file, strip the markers, and turn the
>> actual key's base64 into binary (assuming an RSA key, so there's no "EC
>> parameter" block in front) I now have an "opaque" unsigned character
>> array of length "len" (the decoded Base64) which
>> SSL_CTX_use_privateKey_ASN1 will accept? (Assuming the key file is
>> unencrypted, of course.)
>>
>> What is the parameter "pk" passed to the call in that instance (it's not
>> in the man page)
> From the manpage:
> SSL_CTX_use_PrivateKey_ASN1() adds the private key of type _pk_
>
> So you would need to know that it's an RSA or EC key. If you used
> d2i_AutoPrivateKey you don't need to know the type and get an
> EVP_PKEY.
>
>
> Kurt
Not sure what I'm doing wrong here but obviously its something!
certtemp = *char
certstore = unsigned char* (Both with enough allocated memory to hold
the required data, of course)
const unsigned char *p;
certstore has the Base64 key in it (checked manually, I am reading it
properly from the key file with the barrier lines and line feeds omitted.)
...
strcpy((char *) certstore, certtemp);
p = certstore;
key = d2i_AutoPrivateKey(NULL, , strlen(certtemp));
if (key == NULL) {
ERR_error_string(ERR_get_error(), tmp);
>> return(NULL);
}
..
But I get
$4 = 0xbf3f9b90 "error:0D0680A8:asn1 encoding
routines:ASN1_CHECK_TLEN:wrong tag"
in tmp and a NULL key return from d2i_AutoPrivateKey at the ">>" breakpoint.
If I convert the base64 to binary first -- using the Base64 routine in
OpenSSL (which I know I've coded correctly as the code in question uses
it elsewhere to decode a MIME attachment) and pass a binary buffer and
the length of that buffer (instead of a base64 buffer and its length) I
still get NULL back for the EVP_PKEY structure and the same error text
in tmp.
If I load that same key file with (having put the path to the key file
in tmp) with:
if (SSL_CTX_use_PrivateKey_file(www_context, tmp, SSL_FILETYPE_PEM) < 0)
{.
It loads and works.
What's even MORE odd is that if I do this with the SAME key data I just
loaded in base64 (knowing it's an RSA key):
len = (strlen(certtemp) * 3) / 4 +1;
cbin = decode_base64(certtemp, strlen(certtemp));
if (SSL_CTX_use_PrivateKey_ASN1(EVP_PKEY_RSA, www_context,
cbin, len)) {
ERR_error_string(ERR_get_error(), tmp);
return(NULL);
}
THAT loads (the use_PrivateKey_ASN1 call returns zero -- and thus
obviously likes what I passed it)
There's probably something obvious I'm missing on what I'm doing wrong
with the d2i call -- any quick hit pointers welcome
--
Karl Denninger
k...@denninger.net <mailto:k...@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
smime.p7s
Description: S/MIME Cryptographic Signature
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Question as to best options....
On 12/26/2017 14:07, Kurt Roeckx wrote: > On Tue, Dec 26, 2017 at 01:42:57PM -0600, Karl Denninger wrote: >> On 12/26/2017 13:14, Salz, Rich via openssl-users wrote: >>> So if you put locks around the SSL_CTX object when it’s used, then you >>> can use the set private key call to update the key; and then all >>> SSL_new objects afterwards will use the new credentials. Does that >>> meet your need? >>> >> Yes, that I already know how to do. The issue is how to get the key >> from a PEM file into a format that I can feed it with set private key. >> There doesn't appear to be a means to "un-file-ify" the set private key >> functions. > You can use the d2i_PrivateKey and i2d_PrivateKey functions to read > and write the file. > >>>> "is there a decent way to convert a PEM or DER private key file into >>> ASN.1" using OpenSSL calls (from a "C" program, not from the command >>> line; we'll assume I have the key and cert files already.) >>> >>> I assume you mean “native C structure” and not ASN1? Because DER is >>> just the ASN1 serialized, and PEM is base64 encoded DER with marker >>> lines. … >>> >>> >>> >> So if I take a PEM private key file, strip the markers, and turn the >> actual key's base64 into binary (assuming an RSA key, so there's no "EC >> parameter" block in front) I now have an "opaque" unsigned character >> array of length "len" (the decoded Base64) which >> SSL_CTX_use_privateKey_ASN1 will accept? (Assuming the key file is >> unencrypted, of course.) >> >> What is the parameter "pk" passed to the call in that instance (it's not >> in the man page) > From the manpage: > SSL_CTX_use_PrivateKey_ASN1() adds the private key of type _pk_ > > So you would need to know that it's an RSA or EC key. If you used > d2i_AutoPrivateKey you don't need to know the type and get an > EVP_PKEY. > > > Kurt Thanks - I suspect I have enough to get things rolling :-) -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Question as to best options....
On 12/26/2017 13:14, Salz, Rich via openssl-users wrote: > > So if you put locks around the SSL_CTX object when it’s used, then you > can use the set private key call to update the key; and then all > SSL_new objects afterwards will use the new credentials. Does that > meet your need? > Yes, that I already know how to do. The issue is how to get the key from a PEM file into a format that I can feed it with set private key. There doesn't appear to be a means to "un-file-ify" the set private key functions. > > > "is there a decent way to convert a PEM or DER private key file into > ASN.1" using OpenSSL calls (from a "C" program, not from the command > line; we'll assume I have the key and cert files already.) > > I assume you mean “native C structure” and not ASN1? Because DER is > just the ASN1 serialized, and PEM is base64 encoded DER with marker > lines. … > > > So if I take a PEM private key file, strip the markers, and turn the actual key's base64 into binary (assuming an RSA key, so there's no "EC parameter" block in front) I now have an "opaque" unsigned character array of length "len" (the decoded Base64) which SSL_CTX_use_privateKey_ASN1 will accept? (Assuming the key file is unencrypted, of course.) What is the parameter "pk" passed to the call in that instance (it's not in the man page) int SSL_CTX_use_PrivateKey_ASN1(int pk, SSL_CTX *ctx, unsigned char *d, long len); And likewise, I can just bytewise load a DER file (e.g. read() it into a memory buffer) and then pass that as it's simply a binary copy of the Base64 contained within the markers (plus the EC parameters if it's an ECDSA key)? If so that makes it materially easier than I thought it would be -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Question as to best options....
So let's assume I have system A and B. System A has some store of certificates and keys. We'll assume they're in either PEM or DER format and OpenSSL generated them. System B is going to get passed one or both via a mechanism (e.g. over a TLS connection that it has validated as being "ok" with appropriate cipher and certificate chase, so it's reasonably convinced it's talking to who it thinks it is), and then wishes to install them into executing software so OpenSSL can use them for THAT system to do something with (e.g. take connections from a third machine, sign objects, etc.) I already know how do the "do something" part with OpenSSL. System B does *NOT* want to store these persistently on the disk somewhere (even transiently.) What I'm trying to figure out is the "best" way to handle this. SSL_CTX_use_PrivateKey accepts a EVP_PKEY pointer, SSL_CTX_use_PrivateKey_ASN1 takes an ASN1 structure of length len, but what is parameter "pk" (not explained in the man page) and this assumes I have an ASN.1. I would assume that doing wonky things with EVP_PKEY (like digging into the structure once loaded, grabbing it and transmitting it) is a severely bad idea as the structure may change (e.g. EVP_PKEY is intended to be an opaque structure from a user code perspective.) So that leaves the obvious question as "is there a decent way to convert a PEM or DER private key file into ASN.1" using OpenSSL calls (from a "C" program, not from the command line; we'll assume I have the key and cert files already.) TIA -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] More on cert serialnumbers
On 8/17/2017 09:40, Robert Moskowitz wrote: > I have been researching serial number in cert based on Jakob's comment: > > "- Serial numbers are *exactly* 20 bytes (153 to 159 bits) both as > standalone > numbers and as DER-encoded numbers. Note that this is not the > default in > the openssl ca program. > > - Serial numbers contain cryptographically strong random bits, > currently at > least 64 random bits, though it is best if the entire serial number > looks > random from the outside. This is not implemented by the openssl ca > program." > > And this is supposedly from the CA/B BF? > > Though Erwann responded: > > "There’s no such requirement. It MUST be at most 20 octets long" > > I see how for all certs other than the root (get to that later), I can > control this with: > > openssl rand -hex 20 > serial > > then use 'openssl ca ...' > > But from Kyle's comment, the first bit must be ZERO. So since the 20 octets is a maximum and not a requirement use -hex 19 instead, and if this results in DER placing a leading 0x00 byte you're still ok. This also complies with the ballot that Rich mentioned since you have more entropy than required. At least I think that meets the requirements -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL behavior for NULL characters
On 2/13/2017 18:41, Salz, Rich wrote: >> It is a home grown HTTPS server. > Well, then what does your server do? > > To be very very clear: TLS is a *send the bytes* protocol. It knows nothing > about EBCDIC, ASCII, text, etc. To back up what Rich has said I pass a LOT of data, including HTTPS and binary protocols between different machines (which may contain any particular set of bytes in a packet format) using OpenSSL as the encryption method for said transport and I've had no issues whatsoever with whatever I stuff in the pipe coming out the other end unmolested. Do be aware of the semantics and exceptions (which you must handle -- or else) described in the documentation however -- especially for non-blocking sockets. Due to the potential for renegotiations and similar failing to pay attention to those can result in some pretty interesting "surprises". -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] BIO_read hangs, how can I know if the server wants to send data?
On 4/26/2016 11:12, Hanno Böck wrote: > Thanks for both your answers, that was very helpful (although it > probably means what I'm trying to do is more complicated than I > thought)... > > One more question you might be able to answer: > When I run my test code and connect to google.com I get the following > bytes read for each BIO_read call: > 1024 > 365 > 289 > > When I run these against my own server (relatively standard > apache2.4+openssl setup) I get very different numbers: > 240 > 287 > 2 > 588 > 2 > 41 > 2 > 115 > 2 > 12 > 2 > 110 > 2 > 69 > 2 > 20 > 2 > 6 > 2 > 34 > 2 > 17 > 2 > 12 > 2 > 37 > 2 > 290 > 2 > 6 > 5 > > Why is this so much more split up? And to what correspond these > BIO_read chunks on the protocol level? Are these TLS records? TCP > packets? Is there something horribly wrong with my server config > because it splits them up in so many small parts? > > > It's split up due to the vagaries of TCP and how it delivers packets. In short a local network connection will tend to deliver smaller packets of data than a distant one, all things being equal -- but they never are. All you're guaranteed with TCP is a byte-stream that is coherent, as was noted in the earlier reply, but you are not guaranteed how many bytes will come at once. When select() receives a ready state for reading or a blocking read returns there could be zero (if there's an error, exception, or in the case of SSL a possible protocol renegotiation) or more bytes available to read. There is nothing wrong with either your server or the other end, it's just how it works. Typically the difference is a matter of how things match up between how many bytes are received and buffered in your protocol stack before you read them .vs. how fast the other end can write them and get them to you, which for a wide-area connection usually involves a lot of routers in the middle. With TCP there are additional confounding factors, since the protocol itself implements window control (size of outstanding transmissions that are allowed), sACK can come into play, latency of the circuit and routing points in the middle get involved, etc. For wide-area connections (think Internet) slow-start congestion control (which helps avoid a fast server blasting data at a rate that could otherwise cause a buffer overflow somewhere in the middle, thus requiring a retransmit) also plays a part. -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] regarding SSL security
On 2/12/2016 11:37, R-D intern wrote: > Thank you a lot, Jakob.I understood your answers and am quite satisfied too > that the replies sound conceptually right. But it would be kind on your part > if you answer some questions further. > > 1. Regarding question 3, I am using openssl 1.0.2e which supports named > curve. Such a question had earlier been asked in this forum which says , > such a message is only misleading but the certificate works fine. Here is > the below > link:"http://openssl.6102.n7.nabble.com/ECC-Self-Signed-Certificate-td17042.html#a17047".But > I would like the certificate have a clean structure. How can that be done? > > 2.Regarding question 7, I am working to secure a middleware that will be > deployed in control and monitoring systems, hence there would be know > persons at the client side and the certificates I am using are self signed > ones created using openssl 1.0.2e , hence there will be no public CAs . In > such a scenario , how will the CA know that the private key has been > compromised? If the private key gets compromised, then even the certificate > can be forged ,then what is the use of CRL? > Kindly answer. > Thanks and regards, > Suman Patro > If the CA is private then the CA's public certificate (and any intermediates required to reach it) is loaded into OpenSSL as the chain of validation. That certificate can specify an OCSP or CRL location for revocation checks, which you must then extract and check in your code. "Best practice" for something of this sort requires that _*both*_ ends of the connection present and use certificates, not just the server (in other words you don't want a random client machine connecting either!) which in turn means you need to check for validity and revocation on both ends, /*and */you must ensure the security of the CA infrastructure and its private key. Note that "how the CA knows the client private key is compromised" is an /operational /question, not a programmatic one -- as is the case with a public CA. (In other words someone has to tell the CA it was stolen so the CA can issue the revocation, and the application must check that revocation resource.) -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] SSL version status
On 1/27/2016 07:56, Nulik Nol wrote: > Hi, > I have to implement SSL/TLS in a proprietary web server daemon. I am > only familiar with SSL as a user, not as developer, so my question is. > What versions of SSL should I support for best compatibility and > optimal development time? How much old browsers are out there that > still use older SSL versions? Because, Wikipedia says SSL 3.0 was > deprecated by Jun 2015 but if I only implement TLS, I may lose many > visitors with old browsers, right ? > > Please advise. > TIA > Nulik Some, to use a single word. Not many though. The notable problems come from very old mobile handsets (e.g. Froyo and similar Android). I have about 3% of my users on systems I manage still hitting them from XP machines as an example of "old", which are potential issues in this regard, BUT TLS1.0 is supportable by XP -- so shutting off SSL3 won't kill those users. There are a smattering of machines that still hit my sites running Windows 98, however (well under 1%), believe it or not. Be aware that the OpenSSL defaults when you define a server context are inappropriate for most purposes and thus you have to do a bit more work when programming a server to get a reasonably-secure environment than when connecting using OpenSSL as a client. Specifically, be aware of issues surrounding client renegotiation requests (which can turn into a denial-of-service problem) and how you handle Diffie-Hellman (if you choose to load said keys) along with the ECDH cipher set. For a server you also have to consider whether you're going to multiplex or multithread as OpenSSL requires some additional attention at the programming level (for locking) in a threaded application. -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] (Probably) Silly Application Programming Question
Unfortunately I need a bit more than that. I have two things I'm trying to accomplish, both in the context of checking a client that is connecting to the server: 1. The OpenSSL code by default does not check the OCSP revocation servers when validating a certificate, and I haven't found a "built in" way to do that. Thus, I need to pull out the OCSP responder location from the certificate and check it myself. In this particular application the certificates all come from a private CA which has an OCSP server associated with it, and if a certificate is revoked it's important that it be immediately invalidated. I also wish to have the server operator be given the choice of either allowing the connection to proceed if the OCSP server fails to respond (e.g. is offline temporarily) or to drop the connection. 2. The server has both a "name" (which is usually a shorter version of the hostname; a short "nickname" is nice from a user interface perspective) it expects to connect and a password. While I could simply rely on the presentation of that from the client theft of that tuple would allow any valid certificate-bearing client to impersonate a different client. I can significantly harden against that risk by adding the SAN hostname to the database of names and passwords; now to be considered when the credential is presented the cert associated with that peer has to contain a SAN extension containing the expected DNS name as well. Thus, if you manage to steal a set of login credentials unless you *also* steal the certificate and key associated with it what you managed to get your hands on is worthless. I've got #2 working and am working on #1; it doesn't look all that awful to implement. On 1/13/2016 06:50, Michel wrote: > > Hi Karl, > > > > I believe it could be helpful to have a look at the 509_check_host() > and do_x509_check() source code in crypto\x509v3\v3_utl.c. > > Also, if you want to parse the SAN just for certificate validation, it > is now easier to use : > > https://www.openssl.org/docs/manmaster/crypto/X509_VERIFY_PARAM_set_flags.html > > > > Hope this helps, > > > > Regards, > > > > Michel. > > > > *De :*openssl-users [mailto:openssl-users-boun...@openssl.org] *De la > part de* Karl Denninger > *Envoyé :* lundi 11 janvier 2016 04:08 > *À :* openssl-users@openssl.org > *Objet :* Re: [openssl-users] (Probably) Silly Application Programming > Question > > > > Yeah, now I just have to figure out how to parse the X509 Extension > data from the certificate to pull out the SubjectAltName > information :-) > > There wouldn't be a snippet of code laying around somewhere that does > that given a X509 cert as input would there? It looks a bit arcane > > > > > > ___ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] (Probably) Silly Application Programming Question
I found the problem... for an unexplained reason either the certificate
or key were corrupt; I have added checking to make sure they're
coherent, as apparently OpenSSL is perfectly happy to load a bogus cert
(or key) without throwing an error, but won't present them.
On 1/10/2016 17:07, Judson Wilson wrote:
> On the client side, double check that you are creating the SSL object
> from the context AFTER you set the client cert for the context, and
> not the other way around.
>
> On Sun, Jan 10, 2016 at 2:18 PM, Karl Denninger <k...@denninger.net
> <mailto:k...@denninger.net>> wrote:
>
> I'm sure this is a function of my lack of understanding of the
> documentation, but here it is...
>
> I have an application that implements SSL-encrypted transport
> between two or more devices. For those that are clients without
> certificates (e.g. someone connecting with a web browser) it is
> working fine.
>
> However, I also want certain "things" to connect *with* a
> certificate. Toward that end I have set up a separate context for
> said connections, with (simplified a bit):
>
> master_method = (SSL_METHOD *)
> SSLv23_server_method();/* Create instance */
> master_context = SSL_CTX_new(master_method); /*
> Get SSL context for later */
>
> Then I set up the CA that is going to verify the client
> certificates that are presented, with:
>
> sprintf(tmp, "%s/ssl/ca.pem", CONFIG_DIR);
> if (!SSL_CTX_load_verify_locations(master_context,
> tmp, NULL)) {
> syslog(LOG_ERR, "Cannot load verification;
> MASTER will not validate");
> }
>
> and then load the server-side certificate and key, plus tell it to
> verify the peer.
>
> sprintf(tmp, "%s/ssl/%s", CONFIG_DIR, cert);
> if (SSL_CTX_use_certificate_file(master_context,
> tmp, SSL_FILETYPE_PEM) < 0) {
> syslog(LOG_WARNING, "Cannot load SSL
> Certificate - SSL MASTER DISABLED");
> } else {
> sprintf(tmp, "%s/ssl/%s", CONFIG_DIR, pkey);
> if
> (SSL_CTX_use_PrivateKey_file(master_context, tmp,
> SSL_FILETYPE_PEM) < 0) {
> syslog(LOG_WARNING, "Cannot load
> SSL Key - SSL MASTER DISABLED");
> } else {
> SSL_CTX_set_verify(master_context,
> SSL_VERIFY_PEER, verify_callback);
> master_ssl_possible = 1; /*
> Enable */
> syslog(LOG_INFO, "SSL MASTER
> capability initalized.");
> }
> }
>
> verify_callback just returns the preverify_ok flag back; I don't
> care WHY the verification failed, just whether it did or not. In
> other words looking at the "last reason" is good enough (which I
> can get once the accept fails, if it does.)
>
> Now the client has a very similar set of code in it and when it
> connects it gets the verification (with the callback set to NULL)
> and, provided the certificate verifies against the CA file
> provided, all is well and it works. The client's certificate and
> key are loaded and the same basic code as up above is used to load
> the cert and key without errors being thrown (except, of course,
> that I call SSLv23_client_method() to get the method structure.)
> It also connects *and* properly verifies the server's certificate.
>
> However, on the server side I never get a client certificate back
> despite having loaded one into the context on the client and
> asking for it with SSL_VERIFY_PEER on the server.
>
> If I INSIST on a client certificate by adding the
> SSL_VERIFY_FAIL_IF_NO_PEER_CERT, the connections always fail at
> SSL_accept() with an error indicating that no client certificate
> was provided.
>
> If not, however, the accept succeeds, the verification callback
> routine is never called (!) and when I attempt to get the peer
> certificate with SSL_get_peer_certificate() so I can walk through
> it and check the returned attributes (I wish to use the
> subjectAltName field among others) I get back a NULL.
>
> This has to be something stupid on my part, because I should get
> the verify_callback in any event, I believe -- but I never do.
>
> --
> Ka
Re: [openssl-users] (Probably) Silly Application Programming Question
On 1/10/2016 21:43, Viktor Dukhovni wrote: > On Sun, Jan 10, 2016 at 08:20:41PM -0600, Karl Denninger wrote: > >> I found the problem... for an unexplained reason either the certificate >> or key were corrupt; I have added checking to make sure they're >> coherent, as apparently OpenSSL is perfectly happy to load a bogus cert >> (or key) without throwing an error, but won't present them. > You forgot the validate the loaded cert/key combination via: > > SSL_CTX_check_private_key(ctx); > > which should be called after loading the key and certificate. > Yep. Fixed that, and then found out that the old recipes for walking through the subjectAltName data is no longer workable (apparently the published "book" work on that went rooting around in internal data structures that one should not be playing with). there's a resolution for that too though (just had to dig around a bit), so it's all good now. Thanks... -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] (Probably) Silly Application Programming Question
Yeah, now I just have to figure out how to parse the X509 Extension data from the certificate to pull out the SubjectAltName information :-) There wouldn't be a snippet of code laying around somewhere that does that given a X509 cert as input would there? It looks a bit arcane On 1/10/2016 21:04, Judson Wilson wrote: > It's always good to start with the s_client and s_server programs for > incrementally verifying compatibility in your new programs. Those > would have failed on your certificates, alerting you it's not a > program problem. > > <https://mta.openssl.org/mailman/listinfo/openssl-users> > > > > > ___ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] (Probably) Silly Application Programming Question
I got that book that's what I've been working with. It looks like there have been some internal changes in OpenSSL and this is no longer "appropriate" to use as null dereferences may occur (well, ok, maybe a bit more than "may") :-) Got some ideas here, thanks... I think I'm pointed in the right direction. On 1/10/2016 21:19, Judson Wilson wrote: > I think what you want might be found in the book "Network Security > with OpenSSL" from the year 2002, and the same code snippit can be > found here: > > http://www.cs.odu.edu/~cs772/ssl/c-examples/NSopenssl/common.c > <http://www.cs.odu.edu/%7Ecs772/ssl/c-examples/NSopenssl/common.c> > > look for "post_connection_check". > > This is just something I remember from reading. I have no experience > with it. > > On Sun, Jan 10, 2016 at 7:07 PM, Karl Denninger <k...@denninger.net > <mailto:k...@denninger.net>> wrote: > > Yeah, now I just have to figure out how to parse the X509 > Extension data from the certificate to pull out the SubjectAltName > information :-) > > There wouldn't be a snippet of code laying around somewhere that > does that given a X509 cert as input would there? It looks a bit > arcane > > On 1/10/2016 21:04, Judson Wilson wrote: >> It's always good to start with the s_client and s_server programs >> for incrementally verifying compatibility in your new programs. >> Those would have failed on your certificates, alerting you it's >> not a program problem. >> >> >> >> >> >> >> ___ >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- > Karl Denninger > k...@denninger.net <mailto:k...@denninger.net> > /The Market Ticker/ > /[S/MIME encrypted email preferred]/ > > ___ > 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 -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] (Probably) Silly Application Programming Question
I'm sure this is a function of my lack of understanding of the
documentation, but here it is...
I have an application that implements SSL-encrypted transport between
two or more devices. For those that are clients without certificates
(e.g. someone connecting with a web browser) it is working fine.
However, I also want certain "things" to connect *with* a certificate.
Toward that end I have set up a separate context for said connections,
with (simplified a bit):
master_method = (SSL_METHOD *)
SSLv23_server_method();/* Create instance */
master_context = SSL_CTX_new(master_method); /* Get SSL
context for later */
Then I set up the CA that is going to verify the client certificates
that are presented, with:
sprintf(tmp, "%s/ssl/ca.pem", CONFIG_DIR);
if (!SSL_CTX_load_verify_locations(master_context, tmp,
NULL)) {
syslog(LOG_ERR, "Cannot load verification;
MASTER will not validate");
}
and then load the server-side certificate and key, plus tell it to
verify the peer.
sprintf(tmp, "%s/ssl/%s", CONFIG_DIR, cert);
if (SSL_CTX_use_certificate_file(master_context, tmp,
SSL_FILETYPE_PEM) < 0) {
syslog(LOG_WARNING, "Cannot load SSL Certificate
- SSL MASTER DISABLED");
} else {
sprintf(tmp, "%s/ssl/%s", CONFIG_DIR, pkey);
if (SSL_CTX_use_PrivateKey_file(master_context,
tmp, SSL_FILETYPE_PEM) < 0) {
syslog(LOG_WARNING, "Cannot load SSL Key
- SSL MASTER DISABLED");
} else {
SSL_CTX_set_verify(master_context,
SSL_VERIFY_PEER, verify_callback);
master_ssl_possible = 1; /* Enable */
syslog(LOG_INFO, "SSL MASTER capability
initalized.");
}
}
verify_callback just returns the preverify_ok flag back; I don't care
WHY the verification failed, just whether it did or not. In other words
looking at the "last reason" is good enough (which I can get once the
accept fails, if it does.)
Now the client has a very similar set of code in it and when it connects
it gets the verification (with the callback set to NULL) and, provided
the certificate verifies against the CA file provided, all is well and
it works. The client's certificate and key are loaded and the same
basic code as up above is used to load the cert and key without errors
being thrown (except, of course, that I call SSLv23_client_method() to
get the method structure.) It also connects *and* properly verifies the
server's certificate.
However, on the server side I never get a client certificate back
despite having loaded one into the context on the client and asking for
it with SSL_VERIFY_PEER on the server.
If I INSIST on a client certificate by adding the
SSL_VERIFY_FAIL_IF_NO_PEER_CERT, the connections always fail at
SSL_accept() with an error indicating that no client certificate was
provided.
If not, however, the accept succeeds, the verification callback routine
is never called (!) and when I attempt to get the peer certificate with
SSL_get_peer_certificate() so I can walk through it and check the
returned attributes (I wish to use the subjectAltName field among
others) I get back a NULL.
This has to be something stupid on my part, because I should get the
verify_callback in any event, I believe -- but I never do.
--
Karl Denninger
k...@denninger.net <mailto:k...@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
smime.p7s
Description: S/MIME Cryptographic Signature
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
