On Thu, Oct 24, 2013 at 03:59:08PM -0400, Dave Thompson wrote:
>0 The shutdown is not yet finished. Call SSL_shutdown() for a
> second
>time, if a bidirectional shutdown shall be performed. The output
>of SSL_get_error(3) may be misleading, as an erroneous
>
On Sun, Oct 20, 2013 at 09:29:53PM +0100, Dave Mitchell wrote:
> The man page for SSL_get_error() lists the SSL_* functions it can be used
> with, and it doesn't mention SSL_shutdown().
>
> On the other hand, the man page for SSL_shutdown() says that for
> non-blocking
The man page for SSL_get_error() lists the SSL_* functions it can be used
with, and it doesn't mention SSL_shutdown().
On the other hand, the man page for SSL_shutdown() says that for
non-blocking I/O, you should call SSL_get_error().
So which is right?
I ask, because in the following code:
Can calls to non-blocking SSL_read() and SSL_write() be interleaved?
I'm doing select() / event driven IO, and using a BIO pair to handle the
underlying socket IO myself.
A typical sequence might be:
SSL_read(ssl, read_buf, read_size); /* returns e.g. SSL_ERROR_WANT_READ */
select();
On Fri, Oct 04, 2013 at 10:05:08PM -0400, Dave Thompson wrote:
> > 1) is this a reasonable thing to do?
>
> Yes.
Ok thanks. That's reassuring.
> You don't say why you chose to generate keys centrally. In case you didn't
> know, even with your own CA you *can* still use the conventional process
I'm writing an openssl-based app that uses client and sever certs,
generated using a private root CA. Each client has its own cert and
private key.
For ease of deployment, I'm combining the private key and public cert
into a single file, i.e.:
$ cat client.key client.crt > client.privcrt
Th
