[Openswan Users] CKAIDNSS keyword not found where expected in RSAkey in /var/log/secure
Avesh Agarwal
avagarwa at redhat.com
Wed Jul 8 13:42:23 EDT 2009
Greg Scott wrote:
> OK, the fog in my mind is starting to lift a little bit.
>
> I was looking here:
> http://directory.fedoraproject.org/wiki/Mod_nss
>
> I learned that RedHat bought Mozilla and now wants to use the same SSL
> libraries with Apache that Mozilla uses. Linux has a mature SSL package
> called openssl, but RedHat decided to build its own package called NSS
> (Network Secutity Services) derived from openssl. Both do the same
> things and evidently, the major difference is, NSS keeps a database
> while openssl keeps individual files. Why RedHat wants to build a new
> SSL package is beyond me.
>
> Anyway, now with the latest and greatest release of Openswan, the old
> ipsec.secrets or hostkey.secrets file goes away, and the keys now live
> inside the NSS library. But this can't be completely accurate because
> when I launched ipsec on my F11 box last night, I got the message that
> is the subject of this string. So pieces of Openswan must still reading
> that file. I'll bet what happens is, **the** copy of the key lives in
> the NSS database and then Openswan also makes a copy to live in the
> *.secrets file.
Here is how things works for raw rsa keys as per my understanding.
1. Raw rsa keys (private key and public key) are created inside NSS
database.
2. A copy of public key (formatted according to ipsec.secrets) is kept
inside ipsec.secrets.
3. Private key never comes out of NSS database. That's where better
security is provided by NSS. So ipsec.secrets is not needed to be
confidential any more.
4. A way to find pointer to private key inside NSS database is called
CKAID (Specified as CKAIDNSS in ipsec.secrets, so you know where it
comes).
So in ipsec.secrets, you just have public key and CKAID, no information
related to private key.
> And then over time, all the Openswan utilities will
> evolve to use the NSS database directly - am I getting it?
>
> But I don't understand why go to the trouble? How does putting the RSA
> key or certificate into this database make security any better? Also,
>
Private keys are really private, and never comes out of NSS database, as
I said above. Makes a better security.
Avesh
> just curious, what about non RedHat systems? Is NSS on its way to
> becomnig the world standard?
>
> - Greg
>
>
>
>
>
>
>
> -----Original Message-----
> From: Avesh Agarwal [mailto:avagarwa at redhat.com]
> Sent: Wednesday, July 08, 2009 11:13 AM
> To: Greg Scott
> Cc: Paul Wouters; users at lists.openswan.org
> Subject: Re: [Openswan Users] CKAIDNSS keyword not found where expected
> in RSAkey in /var/log/secure
>
> Greg Scott wrote:
>
>> OK,thanks.
>>
>>
>>
>>> You need to first create a NSS db as follows
>>>
>>> certutil -N -d sql:/etc/ipsec.d
>>>
>>>
>> Looking at the help text on an older f10 box to see what certutil -H
>> does...
>> .
>> .
>> .
>> -N Create a new certificate database
>> -d certdir Cert database directory (default is ~/.netscape)
>> -P dbprefix Cert & Key database prefix
>> .
>> .
>> .
>>
>> So I think the command above creates a new certificate database in
>> /etc/ipsec.d. What is the sql: piece for?
>>
>>
>>
> "sql:" indicates to NSS to use shared database, which is supported in
> fedora.
>
>
>> I am guessing the idea behind this is, I could buy a certificate to
>> "prove" I am who I claim to be and somehow put it in this database and
>>
>
>
>> then use it to generate my RSA key. And therefore my key can be
>> trusted
>> - right? But in this case, I am making a self signed certificate, so
>> I am alleging I am who I claim to be. Am I close to understanding the
>>
>
>
>> idea behind all this?
>>
>>
>>
> "certutil -N" creates certificate database, but when you use "ipsec
> newhostkey" with NSS, it creates only raw rsa keys inside NSS database.
>
> Once you create raw rsa keys inside NSS database, there is no other
> change is required in the way raw RSA keys are used.
>
> For creating certs (not self signed), here is an example:
>
> Creating CA cert with name "cacert1":
>
> certutil -S -k rsa -n cacert1 -s "CN=cacert1" -v 12 -d . -t "C,C,C" -x
> -d <path-to-ipsec.d dir>/ipsec.d
>
> Creating user cert with name "usercert1" signed by "cacert1":
>
> certutil -S -k rsa -c cacert1 -n usercert1 -s "CN=usercert1" -v 12 -t
> "u,u,u"
> -d /etc/ipsec.d
>
>
> So it depends, how you are going to create a certificate. README.nss
> has details about using things with NSS.
>
> Avesh
>
>> If we can hash this out here, I'll be happy to write something up for
>> the community to use.
>>
>>
>>
>
>
>
>> - Greg
>>
>>
>
>
More information about the Users
mailing list