On Feb 1, 12:45 am, Robert Relyea wrote:
> If I were you, I'd double check my byte compare code in B. Try
> connecting to A with one cert and to B with another and make sure it
> fails. In our previous example, you clearly had a mangled version of
> certificate C sent to be, but you indicated tha
On Jan 30, 11:54 am, Nelson B Bolyard wrote:
> B is going to log about the connection from C before it happens?
> uh ...
Yes; A is in fact a server for a centralized peer-to-peer network and
B and C are peers.
It would be useful if the logs of a given peer contained the common
names of other peer
Hello.
I have a problem with NSS. Here's what I'm trying to achieve:
I have systems A and B which have a connection established. Then
system C connects to system A through SSL, identifying itself with a
client certificate. System C is then also expeted to connect to system
B, and in doing so, it m
On Oct 22, 10:32 pm, Wan-Teh Chang wrote:
> I'm wondering if your server is spending some of the 100 ms in
> checking the revocation status of the client certificate. Did
> you enable OCSP checking?
No, haven't configured any OCSP server.
I went through the handshake with a debugger and found th
On Oct 22, 7:22 pm, Nelson B Bolyard wrote:
> What kind of system? What CPU? What clock speed? What memory speed?
>
> Are you doing client authentication with a client certificate?
> Are you using Diffie-Hellman Ephemeral cipher suites?
> 100ms is indeed a long time if you're not.
The system is
ld be hard and non-optimal in
my case.
Thank you for help,
Ambroz Bizjak
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
On Sep 23, 9:01 pm, Wan-Teh Chang wrote:
> This sounds good. Try adding a SSL_ShutdownServerSessionIDCache()
> call before the NSS_Shutdown() call, as our test SSL server selfserv.c does:
That worked, thank you very much.
It should however be documented. The SSL Reference at
http://www.mozilla.o
Hi,
I'm writing a server application using NSS. It appears to be working,
but when it's time to call NSS_Shutdown(), it fails with
SEC_ERROR_BUSY. I've been looking into it and it appears the client
sockets leak PK11SlotInfo references. The leak only occurs when a
handshake completes, and not if a
8 matches
Mail list logo
