> From: owner-openssl-us...@openssl.org On Behalf Of Vieri > Sent: Tuesday, 01 June, 2010 10:25
> --- On Fri, 5/28/10, Dave Thompson <dthomp...@prinpay.com> wrote: > > Are your clients only browsers (IE? FF?) or apps? > > I was testing with IE6 but am now trying out FF 3.5.9. I when > to the advanced config options and tried to import the .der > file from the "Authority" tab. FF complains that "this is not > a certificate authority and cannot be imported". Tried both > cacert.der and cacert.pem. > > So before going any further with server certificates, I guess > I need to find out why FF refuses to import my CA certificate. I think I found it, and it's an extension in the CA cert. I normally use (by hand) the one-step way (req -new -x509) rather than the two-step sequence used by CA.sh (req -new then ca -selfsign). My custom config has no extensions and produces v1, which FF likes, but two-step with standard config used [usr_cert] extensions which has basicConstraints=CA:false. The standard config file has a [v3_ca] section intended for CA cert(s) with CA:true, so it looks like the minimal fix is: on the $CA invocation at line 92+ add -extensions v3_ca . CA.pl has that, and so does CA.sh in 0.9.8m+ and 1.0.0b4+ (and also like CA.pl -create_serial instead of write serial, but still not write crlnumber). (And in both asking for a 'certificate' when we actually want a key if existing, is poor.) I use multiple config files, and editing my CA config and doing two-step makes FF (3.5.9) happy (as does my one-step), but that editing would be a pain with standard single config. Amazingly IE7 on testing likes even CA:false, which is crazy. Although knowing M$ there may be a registry setting somewhere -- or a dozen -- that it's not worth my time to track down. I may try to dig up an old machine still on IE6 and see if that is (was) any different/better. > > And you chose for your CA name a unique value. > > "unique value for my CA name": are you referring to the CN / > Common Name? I guess it is unique. I can name it anything I > want, right? (it doesn't need to be a valid host name of a FQDN) > I regenerated a new test CA cert and its CN is MY-CA-1. > Actually the full Distinguished Name aka DN, which can contain country,state,province,org,orgunit(s),CN, and even other items if supported by the using parties, although CN unique is sufficient to make DN unique. DN definitely shouldn't be the same as any other CA you or your clients trust (or will). This isn't likely to happen by accident, but I just wanted to make sure you hadn't thought it would work to impersonate Verisign or somesuch, or perhaps have a (test) system with data left from another test that chose the same (perhaps convenient) test names. In theory (all?) DN fields can be BMP (approximately Unicode) but AFAICS openssl doesn't make that convenient, and other tools may not either, so IMHO you should limit to ASCII printable, plus avoid characters commonly used in notating DNs (mostly slash, equals, quote, sometimes comma) to avoid confusion. CN doesn't need to be hostname or domainname for a CA cert. Technically not required on entity cert either, but on WWW most parties do want/like entity's CN to be domainname. > I used a custom openssl.cnf and the only differences with the > original file are: > dir = ./MY-CA-HTTP # Where everything is kept > default_days = 1825 # how long to certify for > default_crl_days= 1095 # how long before next CRL > 0.organizationName_default = mydomain.org Fine. Personally I wouldn't put a domainname in organization, but technically it should work. Doing CRLs valid for 3 years would be silly, but I assume you're not actually doing CRLs at all and this is just ignored. > By the way, I'm using openssl 0.9.8k. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
