Re: mod_nss error in logs
Chris Tomlin wrote: > > Hello all, > > I'm getting an NSS error in my httpd logs and it's a bit strange. The error > I'm getting is this: > > Misconfiguration of certificate's CN and virtual name. The certificate CN has > server.name. We expected server.name as virtual name. > > In this error above, server.name is mentioned twice and in both cases it's > the same server name. So that's why it's confusing. > > If anyone has any insight, I would love it since I cannot start my httpd > service. A bit late, sorry. What version of mod_nss? Is this an exact paste of the error message? Is there any more context? rob -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
SSL_BYPASS_PKCS11
SSL_BYPASS_PKCS11 is marked as deprecated in ssl.h. What are the plans on removing it? rob -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS_Context and FIPS
Robert Relyea wrote:
On 10/21/2016 07:04 AM, Rob Crittenden wrote:
I'm trying to figure out how to dynamically enable FIPS support for
NSS Contexts.
I started with multinit.c and initialize FIPS right after calling
NSS_InitContext() using this:
So you can't change the state of an already open database. NSS will
switch all new databases that are opened, and idle the old ones
(basically they are open, but not really accessible).
if (!PK11_IsFIPS()) {
fprintf(stderr, "Initializing FIPS\n");
SECMODModule *mod = SECMOD_GetInternalModule();
if (!mod) {
fprintf(stderr, "No module!?\n");
exit(1);
}
char * internal_name = PR_smprintf("%s",
SECMOD_GetInternalModule()->commonName);
if ((SECMOD_DeleteInternalModule(internal_name) != SECSuccess) ||
!PK11_IsFIPS()) {
fprintf(stderr, "Unable to enable FIPS mode on
certificate database\n");
exit(1);
}
I'm executing it like this, initializing only db1 and db2 as contexts:
So when you do an initcontext, you're main database is usually not the
same as the main database when you open NSS, so it won't get
automatically switched.
A further question: Is NSS_Initialize required or can I just use all
contexts everywhere?
rob
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
NSS_Context and FIPS
I'm trying to figure out how to dynamically enable FIPS support for NSS
Contexts.
I started with multinit.c and initialize FIPS right after calling
NSS_InitContext() using this:
if (!PK11_IsFIPS()) {
fprintf(stderr, "Initializing FIPS\n");
SECMODModule *mod = SECMOD_GetInternalModule();
if (!mod) {
fprintf(stderr, "No module!?\n");
exit(1);
}
char * internal_name = PR_smprintf("%s",
SECMOD_GetInternalModule()->commonName);
if ((SECMOD_DeleteInternalModule(internal_name) != SECSuccess) ||
!PK11_IsFIPS()) {
fprintf(stderr, "Unable to enable FIPS mode on
certificate database\n");
exit(1);
}
I'm executing it like this, initializing only db1 and db2 as contexts:
$ ./multinit --verbose --lib1_db db1/ --lib2_db db2 --lib1_command
list_certs --lib2_command list_certs --lib1_readonly --lib2_readonly
--order 12zi
This is the output:
$ ./multinit --verbose --lib1_db db1/ --lib2_db db2 --lib1_command
list_certs --lib2_command list_certs --lib1_readonly --lib2_readonly
--order 12zi
* initializing with order "12zi"*
*NSS_Init for lib1*
Checking for FIPS
Initializing FIPS
*Executing nss command "list_certs" for lib1*
cacert CTu,Cu,Cu
* Slot=NSS FIPS 140-2 Certificate DB*
* Nickname=cacert*
*
NSS db nicknames with NSS_InitContext()
It looks like when multiple NSS databases are initialized using NSS_InitContext() the nicknames can take multiple forms depending on order of initialization. Using the multinit program and three NSS certificate databases with identical nicknames I saw the following names associated: (first initialized) Server-Cert (second initialized) NSS Certificate DB:Server-Cert (third initialized) NSS Application Token 0005:Server-Cert Is this expected/dependable behavior? It sorta looks like with that third initialization it also has each of the previous two nicknames as well. It seems like rule of thumb is that using multiple databases with the same nicknames is a terrible idea and unpredictable, just looking for confirmation. thanks rob -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: ALPN server support
Martin Thomson wrote:
Yeah, NSS supports ALPN server side.
Just getting back to this. I don't see how this can work.
AFAICT it calls the callback function to select the protocol. The
callback returns a string representing that protocol. But it has no way
of setting the state of the negotiation and NSS doesn't set this either. See
ssl3ext.c::ssl3_SelectAppProtocol()
...
do_callback(...)
if (ex_type == ssl_app_layer_protocol_xtn &&
ss->ssl3.nextProtoState != SSL_NEXT_PROTO_NEGOTIATED) {
/* The callback might say OK, but then it picks a default value
- one
* that was not listed. That's OK for NPN, but not ALPN. */
(void)SSL3_SendAlert(ss, alert_fatal, no_application_protocol);
PORT_SetError(SSL_ERROR_NEXT_PROTOCOL_NO_PROTOCOL);
return SECFailure;
}
The callback has no way to set ss->ssl3.nextProtoState so it remains
SSL_NEXT_PROTO_NO_SUPPORT and ALPN negotiation fails.
curl sees the failure as:
* NSS error -12231 (SSL_ERROR_RX_UNKNOWN_ALERT)
* SSL received an alert record with an unknown alert description.
Is something else supposed to be setting this state?
rob
On Tue, Dec 1, 2015 at 6:53 AM, Rob Crittenden <rcrit...@redhat.com> wrote:
Is ALPN supported on the server side? I can't tell from
the API and Julien asked in
https://bugzilla.mozilla.org/show_bug.cgi?id=959664 but never got an answer.
I'm looking to add HTTP/2.0 support to mod_nss and I need ALPN to do that.
thanks
rob
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Understanding SSL_SetTrustAnchors
I want to control the set of CA certificates available to authenticate client certificates. AIUI I can use SSL_SetTrustAnchors() to do this but it isn't working as I'd expect. The code looks like: CERTCertList * ca_list = CERT_NewCertList(); SSL_SetTrustAnchors(fd, ca_list); (returns SECSuccess) rest of the handshake ... So I'm setting it to an empty list which, as I understand it, no client certs should be accepted. But I find that client certs are still successful when client auth is required. I'm testing using a CA which has two subordinate CA's, one for clients and one for servers. All three CA's are trusted in my server database. Am I doing this wrong or are my expectations wrong? ro -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
server-side OCSP stapling
I don't see a way to implement OCSP stapling on the server side. SSL_SetStapledOCSPResponses() is I think what one would use to set the response in the SSL session but I don't see a way to get the response from the OCSP handler. At least, I don't see a way without implementing my own status checker and overriding statusConfig->statusChecker ala CERT_EnableOCSPChecking(). Am I missing something? thanks rob -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
ALPN server support
Is ALPN supported on the server side? I can't tell from the API and Julien asked in https://bugzilla.mozilla.org/show_bug.cgi?id=959664 but never got an answer. I'm looking to add HTTP/2.0 support to mod_nss and I need ALPN to do that. thanks rob -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
negotiation question
I'm considering how to handle SSL re-negotiation in the Apache NSS
provider mod_nss to handle the SSL client-initiated handshake bug.
NSS provides a callback, SSL_HandshakeCallback(), which according to the
docs is called when an SSL handshake has completed.
So let's say I have the following:
SECStatus FailureHandshakeCallback(PRFileDesc * socket, void *arg)
{
return SECFailure;
}
SECStatus InitialHandshakeCallback(PRFileDesc * socket, void *arg)
{
return SSL_HandshakeCallback(socket, (SSLHandshakeCallback)
FailureHandshakeCallback, NULL)
}
When I create a socket I'll set the handshake callback to
InitialHandshakeCallback(). Once the initial SSL handshake is done this
will then reset it to the failure mode, so that if any subsequent
handshaking happens it will fail.
The Apache configuration lets one have per-location configuration, for
example requiring SSL client auth only for a subdirectory. To do this it
updates the SSL options on the socket and calls SSL_ReHandshake().
What I was thinking about doing here is setting those options, then
setting the callback handler back to InitialHandshakeCallback(). This
should allow the server-initiated handshake to succeed and prevent any
other handshaking (unless we again want to restart it from the server).
Does this (1) seem like a reasonable approach and (2) will it protect
against the client rengotiation issue?
thanks
rob
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: SSL Certificate not found while starting apache with mod_nss
Sandeep Cavale wrote: Hi, I seem to be having the same issue as below... In addition, after such a failure if I do cryptoadm list -v, the hardware provider fails to list my hardware accelerator card (mca0- Sun Crypto Accelerator) Further this is what the /var/adm/messages indicate: Aug 25 15:21:09 crypto genunix: [ID 936769 kern.info] pool0 is /pseudo/p...@0 Aug 25 15:21:09 crypto ipf: [ID 774698 kern.info] IP Filter: v4.1.9, running. Aug 25 16:05:16 crypto genunix: [ID 246487 kern.notice] mca0: Halting processor = Fatal error reported Aug 25 16:05:16 crypto genunix: [ID 246487 kern.warning] WARNING: mca0: Data Abort / TUE AUG 25 10:35:14 2009 Aug 25 16:05:16 crypto exception raised in mcaOMCmd task OM h/w slot is for key management Aug 25 16:05:17 crypto genunix: [ID 246487 kern.warning] WARNING: mca0: Fault interrupt received, halting device @Stefan: Are you still facing the problem? And do you find the above symptoms on you machine too?? IIRC the problem Stefan was having is that Apache runs as httpd and this user wasn't in the unix group that was granted access to the underlying hardware. Apache starts as root and drops privileges so it things would start out good but ultimately fail. Are any errors being logged to the Apache error log? ob -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: API questions
Wan-Teh Chang wrote: Rob Crittenden wrote: Wan-Teh Chang wrote: Rob Crittenden wrote: 2. If I call PR_Shutdown() on an SSL socket, is there a way later to see the flags I called it with? For example, if I call it just with PR_SHUTDOWN_SEND is there a way I can find that out later? I don't think so. Bummer. Would pushing on a layer to store this kind of stuff in fd-secret be overkill? I have some per-connection information I need to store. That'll work. The overhead is a PRFileDesc structure, which consists of 5 pointers and one int. You can also store the per-connection information in a PLHashTable. Wan-Teh I ended up going with a layer that doesn't define any methods. Seems to be working ok. I originally assumed the order of the layers and would do things like: mydata = ssl-lower-secret but later changed it to fetch the layer by name and retrieve the data directly. I didn't want to assume that nobody else would push a layer on at some point. thanks rob ___ dev-tech-crypto mailing list [EMAIL PROTECTED] https://lists.mozilla.org/listinfo/dev-tech-crypto
API questions
I've got a couple of API questions. I'm not sure if these are available or not: 1. Can I get the numeric value of the cipher that has been negotiated instead of just the character value (e.g. from SSL_SecurityStatus())? 2. If I call PR_Shutdown() on an SSL socket, is there a way later to see the flags I called it with? For example, if I call it just with PR_SHUTDOWN_SEND is there a way I can find that out later? rob ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Forcing the SSL handshake
Nelson B wrote:
Rob Crittenden wrote:
In an SSL client I want to force the SSL handshake to take place instead
of passively waiting for it to happen during the first write.
Right after I connect to the server I'm currently doing this:
SSL_ResetHandshake(ssl, /* asServer */ PR_FALSE);
do {
SSL_ForceHandshake(ssl);
PR_Recv (ssl, handshake, 1, PR_MSG_PEEK, 100);
err = PR_GetError();
} while (err != PR_END_OF_FILE_ERROR handshake_done == 0);
This code may also run into bug 273861.
https://bugzilla.mozilla.org/show_bug.cgi?id=273861
Be sure there's no unread data on the sslsocket before calling ForceHandshake.
Yup, the poll did the trick. I used PR_Recv because I knew it would
force the handshake without doing any unexpected I/O (on the off-chance
there actually WAS something to read. Didn't even consider using
PR_Poll, it is working nicely.
One change I've made from tstclnt is using PR_ConnectContinue() instead
of PR_GetConnectStatus() which is deprecated.
The socket is already connected by the time I start doing any NSS calls.
I'm getting a connected socket and pushing SSL on top of that (rather
than doing PR_Connect() myself).
Do you know if this comment from tstclnt is still true?
/* Must milliPause between PR_Poll and PR_GetConnectStatus,
* Or else winsock gets mighty confused.
* Sleep(0);
Do I really need a millisecond pause between the poll and
PR_ConnectContinue()?
thanks
rob
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Forcing the SSL handshake
In an SSL client I want to force the SSL handshake to take place instead
of passively waiting for it to happen during the first write.
Right after I connect to the server I'm currently doing this:
SSL_ResetHandshake(ssl, /* asServer */ PR_FALSE);
do {
SSL_ForceHandshake(ssl);
PR_Recv (ssl, handshake, 1, PR_MSG_PEEK, 100);
err = PR_GetError();
} while (err != PR_END_OF_FILE_ERROR handshake_done == 0);
If the handshake succeeds the my SSL_HandshakeCallback callback sets
handshake_done and I exit the loop. If it fails then sooner or later
PR_Recv will set the error to EOF. I don't care if I'm losing the error
from the handshake, I do the logging for failures in the
SSL_BadCertHook() callback.
My questions are:
1. Do I need the loop or will the PR_Recv, even with such a short
timeout, do the trick for me?
2. Is there a better way to do this?
rob
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Forcing the SSL handshake
Nelson B wrote:
Rob Crittenden wrote:
In an SSL client I want to force the SSL handshake to take place instead
of passively waiting for it to happen during the first write.
Right after I connect to the server I'm currently doing this:
SSL_ResetHandshake(ssl, /* asServer */ PR_FALSE);
do {
SSL_ForceHandshake(ssl);
PR_Recv (ssl, handshake, 1, PR_MSG_PEEK, 100);
err = PR_GetError();
} while (err != PR_END_OF_FILE_ERROR handshake_done == 0);
If the handshake succeeds the my SSL_HandshakeCallback callback sets
handshake_done and I exit the loop. If it fails then sooner or later
PR_Recv will set the error to EOF. I don't care if I'm losing the error
from the handshake, I do the logging for failures in the
SSL_BadCertHook() callback.
Here are a few (?) questions and comments:
1. Is this a blocking socket, or non-blocking?
non-blocking, not my choice.
2. If non-blocking, are you certain that the connection has completed?
That is, are you certain that the TCP's three phase connect is
completely done? This is tricky for non-blocking sockets, and trivial
for blocking sockets.
I'm not sure it has completed, hence the simplistic loop and my plea for
assistance. Despite empirical evidence that it worked in my 3 test
cases this code is obviously bogus.
3. Is this the first handshake on the socket after the connect? or
Is it a subsequent (e.g. second) handshake on the socket?
First connection only.
4. Is this a server speaks first application protocol? or
is this a client speaks first protocol?
Client speaks first, HTTPS.
5. What if some other error occurs besides PR_END_OF_FILE_ERROR?
This loop continues. IMO, it should not. Some errors leave the
SSL socket in a state where it cannot continue. This includes
PR_IO_TIMEOUT_ERROR, if I'm not mistaken.
If you ignore the error code and call an I/O function on the SSL socket
again, it will return an error again immediately. As coded, this will
be an infinite loop.
Yup, that's what I'm worried about.
I guess at least the loop should be:
do
ret = PR_Recv (ssl, handshake, 1, PR_MSG_PEEK, 100);
err = PR_GetError();
while (ret 0 err == PR_IO_TIMEOUT_ERROR handshake_done == 0);
On slow connections I've seen the loop fire as many as 20 times. I can
increase the timeout, that is purely a goof. But again, I don't want a
noticable pause. On connections to a local machine even with an interval
of 1 sometimes the handshake completes in one run through the loop (and
who said SSL is slow?)
6. IMO, you need to check every SSL call (and that includes PR_Recv)
to see if it succeeded or failed, and not continue to use the socket
on failure. PR_WOULD_BLOCK_ERROR (a.k.a. EWOULDBLOCK) is obviously
an exception to this rule, but needs to be handled with PR_Poll.
Yes, you're right, I was being lazy, but in this case it will ALWAYS
fail since there should never be any data to peek at since this is the
first (and only) connection. But I suppose I should consider the case
where the remote closes he connection as well, see above for that fix.
7. Why are you using such a short timeout on PR_Recv?
So it doesn't cause a noticable pause in the connection. There will
never be any data to peek at so I am guaranteed to wait a certain
number of PRIntervals until PR_Recv returns. A larger value will almost
certainly negate the need for the icky loop but even if the handshake is
done, it'll hang around waiting for the timeout to end.
8. Why are you using SSL_ForceHandshake at all?
Why not use PR_Recv to do both the handshake and receive the first
application message?
No reason, it works as well without it.
My questions are:
1. Do I need the loop or will the PR_Recv, even with such a short
timeout, do the trick for me?
What trick are you trying to do?
Force a handshake to complete on a non-blocking socket without doing I/O
with PR_Send/Write or PR_Read/Recv (in non-peek).
2. Is there a better way to do this?
I'm sure the answer is yes, but I can't advise you of an optimal solution
without knowing the answers to my questions above. Also I don't really
understand what you're trying to achieve with this loop.
The usual reason for using SSL_ForceHandshake is when you're in a second
handshake situation, where you're a server, you've received a request,
you expect to receive nothing more until you've sent the response,
you've started a second handshake to request client auth, and you
have nothing to send until that handshake finishes. In that case, it
is not appropriate to call either PR_Send/Write nor PR_Recv/Read, so
you need SSL_ForceHandshake. In most other situations, where you're waiting
for the other side to send you something, you can just use PR_Recv/Read
to accomplish the handshake and wait for the message. On a blocking
socket, no loop is needed.
In this case, you're the client and you're waiting for the server to say
something
Re: NSS Cache question
Nelson B wrote: Rob Crittenden wrote: I'm having an issue with mod_nss, an Apache module I wrote that provides SSL using NSS. The way Apache loads modules is a tad strange. I'd say it's more than a tad! What it does is it loads them one time in order to get its list of configuration directives and it verifies that the configuration is ok. It also runs through the initialization routines. In my case this is needed so I still have stdin/stdout and can prompt for the PIN. Can't you use /dev/tty instead of stdin/stdout? I suppose so, I'll look into that for the future but it would require a fair bit of restructuring. Once the first round of module loading is done stdin/out/err are all closed. Apache then unloads the module, then reloads it again. I'm not really asking you to defend any of that, but ... do you have any idea what (if anything) is the benefit of that strategy? Each module can provide its own set of configuration directives. Apache needs to figure out what those are so it loads the module to find them. I'm not entirely sure why it runs the init and shutdown though. Perhaps for the stdin/stdout problem. I had to write a fair bit of code to handle this, in particular because NSS needs to shut down gracefully otherwise it won't start up again once the module gets loaded for the 2nd time. Yes, that's not uncommon. Opens need to be closed, mallocs need to be freed (as you know :). The specific problem I'm having is with the NSS session cache. You know that NSS has (potentially) two separate session caches, the client cace (of sessions which NSS began by acting as an SSL client), and the server session cache (of sessions for which NSS acted as the server). They're managed entirely separately. Yes, the current problem is the server cache. I periodically get a core dump in the LockPoller thread (sslsnce.c). In this case, it is apparent that you're discussing the server cache. The server cache can operate in either of two modes: single process or multiple process. There are separate server cache initialization functions, one for single process server caches, and another for multi-process server caches (it has the letters MP in the name). In the latter case, the server session cache is kept in shared memory, so that multiple processes can all share a single common pool of sessions. One process creates the cache in unnamed (a.k.a. anonymous) shared memory and the other processes that share it must all inherit it as children of the process that created it. The parent process also creates a thread to watch the shared memory, to deal with the possibility that one of the children might die while holding a lock in that shared memory. Right, I have to handle both cases. Apache has a multi-process and a multi-threaded mode. On some unix/linux systems, there is a problem if the parent has multiple threads going when it forks a child. So we need to have a way to stop the lock poller thread prior to fork, and start it up again in the parent after the fork. See https://bugzilla.mozilla.org/show_bug.cgi?id=339466 Yes, this bug sounds like my problem. The cache is disappearing underneath the thread and bad things happen. It's basically a race condition to see if this thread can exit before its data disappears. The lock poller thread definitely needs to be stopped in the parent process before unloading the module. However, there is an issue here regarding inheritance. It would be wrong to create the shared memory cache in a parent process, fork the children, then shutdown the shared memory cache and create another one. So, this raises numerous questions and ideas. I'll start with one question. Q1) Is this a multi-process shared server cache installation? Do you intend to operate the shared memory session cache? If not, the easiest solution is for you to use the single proecss server session cache. It is multi-process (we're talking Apache here) and I don't really have a choice in the matter. A potential fix I have is to not initialize the cache during the first module load. Seems to me that your options might include: a) do NOTHING on the first module load, and do everything on the second module load. b) do all the work on the first module load. Don't really shut down the module after the first load (that is, pretend that you shut down). Then do nothing on the second load, and continue to use the stuff loaded the first time. c) really startup and shutdown everything all the way twice. I'm doing c) now and it's crashing, unless I've missed something. It definitely seems like a timing bug because it doesn't crash all the time and tends to crash more on slower machines than faster ones. I don't have the choice with b). Apache forcibly unloads the module (dlcose()). If I haven't shut things down right I'll get a SEC_ERROR_BUSY error during subsequent reloads. I can't do a) because of the stdin/stdout
NSS Cache question
I'm having an issue with mod_nss, an Apache module I wrote that provides SSL using NSS. The way Apache loads modules is a tad strange. What it does is it loads them one time in order to get its list of configuration directives and it verifies that the configuration is ok. It also runs through the initialization routines. In my case this is needed so I still have stdin/stdout and can prompt for the PIN. Once the first round of module loading is done stdin/out/err are all closed. Apache then unloads the module, then reloads it again. I had to write a fair bit of code to handle this, in particular because NSS needs to shut down gracefully otherwise it won't start up again once the module gets loaded for the 2nd time. The specific problem I'm having is with the NSS session cache. I periodically get a core dump in the LockPoller thread (sslsnce.c). The cache is disappearing underneath the thread and bad things happen. It's basically a race condition to see if this thread can exit before its data disappears. A potential fix I have is to not initialize the cache during the first module load. I've always been under the impression that initializing the cache is one of the things one should do in an NSS app and I don't want to introduce other, worse side-effects. Assuming that is ok, is it bad to call SSL_ShutdownServerSessionIDCache() if the cache hasn't been initialized? I briefly looked at the code and it seems ok to me but I don't want to make assumptions. thanks rob ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS Apache module - mod_nss
Nelson B. Bolyard wrote: Rob Crittenden wrote: A fair bit of work has been done to mod_nss, an SSL module for Apache that uses NSS instead of OpenSSL, since it was released last September. Changes since then include use the NSS OCSP client, addition of a FIPS mode (similar to modutil -fips true -dbdir /path/to/database), options to seed the NSS Random Number Generator, support for Apache 2.2 as well as a number of important bug fixes. Rob, You da MAN! Seriously, I really appreciate the work you (and others?) have done on this! Thanks :-) I can't take all the credit. Wan-Teh and Bob R. were very helpful during the module development and the Apache 2.2 compatibility code was contributed. cheers rob ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
NSS Apache module - mod_nss
A fair bit of work has been done to mod_nss, an SSL module for Apache that uses NSS instead of OpenSSL, since it was released last September. Changes since then include use the NSS OCSP client, addition of a FIPS mode (similar to modutil -fips true -dbdir /path/to/database), options to seed the NSS Random Number Generator, support for Apache 2.2 as well as a number of important bug fixes. If anyone is interested in trying this out I've created RPMS for RHEL 4 and Fedora Core 4 and 5. It should be as simple as installing a couple of RPMS and firing up Apache. The default listener is 8443 since I don't want it to interfere with any existing OpenSSL configuration. mod_nss can co-exist with mod_ssl in the same server. You can find out more about mod_nss and download the binaries and/or source from http://directory.fedora.redhat.com/wiki/Mod_nss cheers rob ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
