Anders Rundgren wrote:
>> NSS (and therefor mozilla products) do not do automatic fetching of
>> certificates at this point in time.
>
>> Currently all protocols have a way of transmitting the necessary
>> intermediate certificates, and mozilla products depends on these protocols.
> In theory ye
Converse: If it's confusing, it's broken. Maintenance is a primary
concern, and transparency is a primary concern in maintainable code.
If someone's digging deeply enough to get confused by it, and there's
inconsistency (aka obscurity) in the code that is examined when they
look at it, it might b
Peter Djalaliev wrote:
> If ss->securityHandshake is not used anymore, maybe both functions
> should set the handshake function using the ss->handshake function
> pointer to avoid confusion. Also, would getting rid of the
> ss->securityHandshake pointer altogether be possible, too? This would
>
Wan-Teh Chang wrote:
> Nelson Bolyard wrote:
>> I tried the above command when the module was not in FIPS mode, and the
>> above command also failed.
>> ERROR: Token "NSS FIPS 140-2 Certificate DB" not found.
>
> Try the token name "NSS Certificate DB" in non-FIPS mode.
I am trying to reproduce
Alex wrote:
I compiled nss on FreeBSD platform, and wrote a program .
My program use function SECU_ReadDERFromFile, like this
#include "secutil.h"
..
rv = SECU_ReadDERFromFile(&certDER, inFile, PR_TRUE);
..
This function is in libsectool.a
#nm libsectool.a |grep SECU_Read
1290 T S
Nelson Bolyard wrote:
David Stutzman wrote:
I'm doing it like this:
modutil -changepw "NSS FIPS 140-2 Certificate DB" -dbdir .
[...]
I tried the above command when the module was not in FIPS mode, and the
above command also failed.
ERROR: Token "NSS FIPS 140-2 Certificate DB" not found.
Thank you for your prompt reply.
Bob wrote:
>NSS (and therefor mozilla products) do not do automatic fetching of
>certificates at this point in time.
>Currently all protocols have a way of transmitting the necessary
>intermediate certificates, and mozilla products depends on these protocols.
In
David Stutzman wrote:
> Bob Relyea wrote:
>> David Stutzman wrote:
In FIPS mode, the NSS cryptographic module imposes the following
requirements on the password.
* The password must be at least seven characters long.
* The password must consist of characters
I compiled nss on FreeBSD platform, and wrote a program .
My program use function SECU_ReadDERFromFile, like this
#include "secutil.h"
..
rv = SECU_ReadDERFromFile(&certDER, inFile, PR_TRUE);
..
This function is in libsectool.a
#nm libsectool.a |grep SECU_Read
1290 T SECU_ReadDERFro
Both your root.cert and cacert.cert seem to have same serial number and
issuer.
That is forbidden.
But even if your certs had unqiue serial numbers, I don't know whether
NSS would be able to fetch that intermediate dynamically from the web. I
doubt it.
Kai
Anders Rundgren wrote:
The follo
Julien,
Just checked FF and NS. Both have the buttons of login and logout for
Security Devices. The manner you provided allows me to remove the SSL
caching, but it also erases the exisiting SSL connection. This will not
work for some situations.
Anyway, thanks a lot for your help.
Ben
Julien
NSS (and therefor mozilla products) do not do automatic fetching of
certificates at this point in time.
Currently all protocols have a way of transmitting the necessary
intermediate certificates, and mozilla products depends on these protocols.
Automatic fetching is a PKIX feature, and is tar
The following 3-level certificate hierachy works as expected when looking on it
in MSIE:
Root certificate: http://webpki.org/mozbug/root.cer (to be imported)
Actual CA certificate: http://webpki.org/mozbug/cacert.cer (NOT to be imported
since the EE cert's AIA CAissuers URI points to this)
EE c
Allan (beaufour), you should be able to build the CFB128 mode
yourself using the ECB mode as a primitive. It seems
straightforward to me (because 128 is the block size, you
don't need to shift). This way you don't need to wait for
the support of AES in CFB128 mode in NSS.
The NIST AES validatio
Bob Relyea wrote:
David Stutzman wrote:
In FIPS mode, the NSS cryptographic module imposes the following
requirements on the password.
* The password must be at least seven characters long.
* The password must consist of characters from three or more
character classes. We define five
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Wan-Teh Chang wrote:
[EMAIL PROTECTED] wrote:
Wan-Teh Chang wrote:
Why would you like to use the CFB mode?
Because that's what the current (non-NSS) code does. I'd rather just
port, not change, the code.
shinigami wrote:
Are you two working together, by any chance?
Yes, in the same project. Sorry for duplicated post. A communication
mistake.
Now I will go to try explain my situation.
I�m developing a java aplication. My aplication already list the tokens and
modules when they are inserted bef
David Stutzman wrote:
In FIPS mode, the NSS cryptographic module imposes the following
requirements on the password.
* The password must be at least seven characters long.
* The password must consist of characters from three or more
character classes. We define five character classes:
Helson,
Thanks for you reply :)
> > What is the ss->securityHandshake used for?
>
> I think it may now be unused. I think it was part of the old SOCKS
> implementation that was abandoned.
>
This probably doesn't matter as much, but ssl_SecureConnect sets the
handshake function using ss->securit
19 matches
Mail list logo
