Errata

It seems that the "openssl" command cannot get the number of days and bits set in the configuration file cannot be taken (so it is a problem of the "openssl" command itself).

The following command works OK:

openssl req -config /opt/TMBca/openssl.cnf -x509 -newkey rsa:2048 -days 365 -out cacert.pem -outform PEM

Without specifying the days in the command line, then the number of days is one month (irrespective of the fact that in the configuration file it is set as 365).

With current openssl versions, the rsa argument to the newkey option requires the bits. The full command then becomes:
openssl req -x509 -newkey rsa:2048 -out cacert.pem -outform PEM

Attributes:
unstructuredName :drowssap egnellahc
challengePassword :drowssap egnellahc

Should be: (Tested under OpenSSH 0.9.7a)
Attributes:
unstructuredName :Examples-R-Us, Inc.
challengePassword :cloud noon sundry presto madrid baker

The described error function:

char *ERR_error_string_n(unsigned long e, char *buf, size_t len);

should be:

void ERR_error_string_n(unsigned long e, char *buf, size_t len);

at least for OpenSSL 0.9.6.d...

(r = pow(a, 2) % m) should be (r = pow(a, p) % m)
for BN_mod_exp(r, a, p, m, ctx)

The THREAD_CREATE macro (for windows) appears to attempt to return an identifier for
the newly created thread. The code, however, will always return the id of the thread
that called the macro.

To return the identifier of the new thread the macro should be modified so read:-

#define THREAD_CREATE(tid, entry, arg) do {
(tid) = GetThreadId (_beginthread ((entry), 0, (arg)))
} while (0);

Because 'GetThreadId' uses the handle returned by _beginthread to retrieve the
identifier of the newly created thread.

Examples 4-9 through 4-12 define a function seed_prng() defined as:
int seed_prng(int bytes)

But in several of client/server examples in Chapter 5 (Examples 5-5, 5-6, 5-9, and 5-
10) the usage appears to be
void seed_prng(void).
Suggest changing the Chapter 5 examples to show:
seed_prng(1024);

server_thread() function should return pointer (to suppress compile warning). So
line 21 should read:
void *THREAD_CC server_thread(void *arg)
rather than
void THREAD_CC server_thread(void *arg)

Lines 54-58 should be 53-57

"Line 56 does this through a call to SSL_set_bio."
should read:
"Line 55 does this through a call to SSL_set_bio."

Line 56 should be 55.

The for loop will just loop forever, so line 40 will never be reached - leaving a
dangling thread. Could change it to a do loop as in example 5.6.

The variables "have_data_A2B" and "have_data_B2A" are unnecessary. Conditional statements in the example can check for "A2B_len > 0" and "B2A_len > 0", respectively.

Example 16 in chapter 5 has a fundamental flaw. It uses check_availability to determine
whether to call SSL_Read, so this only happens (renegotiation aside) when the appropriate
bit corresponding to the SSL fd is set in the read fdset. However, this is to ignore
the fact that the SSL reads ahead. So, if a read is done which fills the buffer, and
there is more data read ahead, but no more data beyond that, the SSL_Read will never be
called to read the internally buffered data (i.e. the data that has been read ahead).

The way to fix this is something like (untested) adding:

can_read_A |= SSL_Pending(A);
can_read_B |= SSL_Pending(B);

after check_availability, and then for the text to explain what SSL_Pending does (returns
true if there is buffered data).

The second sentence in the 3rd paragraph references a non-implemented funciton called
set_nonblocking. The function is actually written (in the example code on page 160)
as set_non-blocking.

"They assert we are not in the middle of a read operation..."
should read
"They assert we are not in the middle of a write operation..."

"They assert we are not in the middle of a read operation..."
should read
"They assert we are not in the middle of a write operation..."

I'm not reporting errors for XCBC-MAC but would like to give suggestions. It would be better and more practical if the code shown in this section could comply the functions specified in RFC 3566.

The certificate request generated with the sample code will NOT work correctly with
some certificate authorities (for example Verisign). The problem is that the code
fails to set the version number. The following line of code should be added after
creating the request (with X509_REQ_new()):

X509_REQ_set_version(req, 0L);

fprintf(stderr, "Error reading the CRL file
");
should read
fprintf(stderr, "Error reading the CA directory
");

fprintf(stderr, "Error reading the CRL file\n");
should read
fprintf(stderr, "Error reading the CA directory\n");