Re: moznss with openldap - error -8018:Unknown PKCS #11 error
Fixed: I did: -recreate /etc/openldap/certs moznss database -chown root:ldap -R /etc/openldap/certs/ -chmod 640 /etc/openldap/certs/* -recreate /etc/openldap/slap.d/ now it works like a charm I was missing either file permission to read the database, or there was mismatch between pkcs12 key and pem certificate. either way - now it works. Best regards. Augustyn On 8 August 2013 07:38, Augustin Wolf augustynw...@gmail.com wrote: Hi List, I have a Centos 6.4, fresh install, and I'm trying to configure OpenLDAP with moznss. For now, self signed certificate is sufficient for my needs. But when I try to search using secure connection (-Z option), I got error: ldap_start_tls: Connect error (-11) additional info: TLS error -5938:Encountered end of file In openLdap logs: connection_read(14): checking for input on id=1000 TLS: certdb config: configDir='/etc/openldap/certs/' tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly TLS: cannot open certdb '/etc/openldap/certs/', error -8018:Unknown PKCS #11 error. TLS: skipping 'cert8.db' - filename does not have expected format (certificate hash with numeric suffix) TLS: skipping 'key3.db' - filename does not have expected format (certificate hash with numeric suffix) TLS: skipping 'secmod.db' - filename does not have expected format (certificate hash with numeric suffix) TLS: error: the certificate 'LDAPServer' could not be found in the database - error -8187:security library: invalid arguments.. TLS: could not read certificate file LDAPServer - error -5950:File not found. TLS: error: could not initialize moznss security context - error -5950:File not found TLS: can't create ssl handle. connection_read(14): TLS accept failure error=-1 id=1000, closing connection_close: conn=1000 sd=14 I cannot resign from using moznss, as it is in default with openldap package in CentOS 6.4. I created TLS certificates like this: [root@ldap ~]# openssl req -new -x509 -extensions v3_ca -keyout /etc/pki/CA/private/CAss.key -out /etc/pki/CA/certs/CAss.pem -days 200 #got rid of certificate password: [root@ldap ~]# openssl rsa -in /etc/pki/CA/private/CAss.key -out /etc/pki/CA/private/CAssNOpass.key #created pkcs12 key+cert [root@ldap ~]# openssl pkcs12 -export -inkey /etc/pki/CA/private/CAssNOpass.key -in /etc/pki/CA/certs/CAss.pem -out /etc/pki/ldap.example.com.p12 -nodes -name 'LDAPServer' #import p12 certificate to openldap keybase: [root@ldap ~]# pk12util -i /etc/pki/ldap.example.com.p12 -d /etc/openldap/certs #import CA, as CA to certificate keybase: [root@ldap ~]# certutil -A -d /etc/openldap/certs -n LDAPServer -t CT,, -i /etc/pki/CA/certs/CAss.pem # verify: [root@ldap ~]# certutil -d /etc/openldap/certs -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI LDAPServer CTu,u,u # keybase has ldap permission, and ldap is able to read from it: [root@ldap ~]# chown root:ldap /etc/openldap/certs/* [root@ldap ~]# chmod 0640 /etc/openldap/certs/* #openldap uses this keystore: [root@ldap ~]# cat /etc/openldap/slapd.conf |grep -i tls TLSCipherSuite HIGH:MEDIUM:+SSLv3 TLSCACertificatePath /etc/openldap/certs TLSCertificateFile LDAPServer TLSVerifyClient allow What I did wrong? Best regards, Augustin -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On 08/09/2013 04:30 AM, Brian Smith wrote: Please see https://briansmith.org/browser-ciphersuites-01.html First, this is a proposal to change the set of sequence of ciphersuites that Firefox offers. So I think there are a whole bunch of things where we have 2 options, and it's not always clear which is more important. We have: - PFS or not - ECC or not - RSA or DSA - GCM or CBC - keysize (128 vs 256) - cipher itself - The used MAC As far as I understand things, most of those don't have a big impact on security, but do on the speed. I think it makes sense to have PFS when the other side supports it, so that part of the order looks good to me. We clearly want (EC)DHE when possible. DH should probably be avoided. I understand that ECC might be more secure and is faster, so you want to prefer ECC. But currently there aren't many servers that have ECDHE yet, so we should be careful what the order is in case it's not available and try to use DHE in that case. The current list didn't do that but this one does. I'm not sure which of RSA and DSA is better, but clearly people use RSA more. I understand that GCM is faster, but the implementations might have side channel attacks. So I'm not sure if GCM or CBC is better, but we should probably prefer GCM or CBC. I understand that for a 2048 bit public key a 128 bit symmetric key should be good enough, but for a 4096 you should have a larger key. I see that about 2% is using keys of 4096 bit. As far as I understand it, there is nothing wrong with 3DES other than that it's slower. RC4 should clearly be deprecated, but is currently popular because BEAST and that it's the only stream cipher we have. Since we know we're not vulnerable to that, it make sense to order this as late as possible. It might not be obvious, but camellia is currently used a lot when connecting to sites because it's the first non-ECDHE in the current list. And the RSA key-exchange was even before the DHE version. I understand that the MAC itself doesn't make much difference, but we should probably avoid MD5. I see no SHA256 MACs except for GCM which probably isn't a problem. So I can mostly follow the reasoning behind the proposed order, but I'm a little bit surprised that we used to have all the 256 bit before the 128 bit, and it's now the other way around. I don't really see this as a problem except for people that want to use 4096 bit public keys. They should probably disable 128 bit keys on their server. I'm not sure why you keep TLS_DHE_DSS_WITH_AES_128_CBC_SHA and drop TLS_DHE_DSS_WITH_AES_256_CBC_SHA I'm concerned that DHE_RSA_WITH_3DES_EDE_CBC_SHA is dropped, since it's the only one with PFS that some sites support. Can I suggest you add that before the ECDHE_*_RC4 ciphers? Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On Mon, Aug 19, 2013 at 08:06:49PM +0200, Kurt Roeckx wrote: I understand that the MAC itself doesn't make much difference, but we should probably avoid MD5. I see no SHA256 MACs except for GCM which probably isn't a problem. I'm having mixed feelings about SHA1 / SHA256. I think it makes sense to move to SHA256 even when SHA1 isn't broken as used here. But since we do this already use it for GCM, and that's on top of the list, I think it's fine. I'm concerned that DHE_RSA_WITH_3DES_EDE_CBC_SHA is dropped, since it's the only one with PFS that some sites support. Can I suggest you add that before the ECDHE_*_RC4 ciphers? I also just noticed that all GCM suites we have are ECDHE versions. I would like to have a DHE version too since apache 2.2 doesn't support ECDHE but does have support for the DHE GCM ciphers. I would like to see that as first non-ECDHE cipher in the list. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On 19/08/13 04:07, Brian Smith wrote: When risk is there to a user of having a network eavesdropper able to tell that they are using a particular browser? If I had an exploit for a particular browser, I'd just try it anyway and see if it worked. That seems to be the normal pattern. One example is Tor: it tries to look like a normal browser so that it is hard to detect that you are using Tor. And, if Tor is properly configured then the network attacker will never see any non-TLS traffic. But if Tor Browser is based on Firefox, then it'll have the same TLS signature as Firefox anyway? Gerv -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On 20 August 2013 14:26, Gervase Markham g...@mozilla.org wrote: On 19/08/13 04:07, Brian Smith wrote: When risk is there to a user of having a network eavesdropper able to tell that they are using a particular browser? If I had an exploit for a particular browser, I'd just try it anyway and see if it worked. That seems to be the normal pattern. One example is Tor: it tries to look like a normal browser so that it is hard to detect that you are using Tor. And, if Tor is properly configured then the network attacker will never see any non-TLS traffic. But if Tor Browser is based on Firefox, then it'll have the same TLS signature as Firefox anyway? Not Tor Browser, but the Tor protocol itself. For more information, the spec document that deals with this is: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/198-restore-clienthello-semantics.txt -tom -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
