Bug 511327

the error message during pki-tps setup is thrown on the "Subject Names" panel where it says

"CA returned no response. Please check that the CA is available and also check the host's firewall settings. "

there's no firewall enabled on any of the 4 hosts

After some analysis - its clear that the installation fails because the Server Cert fails to be inserted in the token. Unlike the other subsystems which install their certs through jss - the TPS and RA use certutil to install their certs. 

Specifically, the cert request is generated from a certutil command similar to the following:

certutil -R -s "CN=seraph.dsdev.sjc.redhat.com, OU=pki-tps03, O=mouse lunasa alee 0727 manualtest" -k rsa -g 2048 -d /var/lib/pki-ca/alias -h lunasa2-ca -a

This request is sent to the CA, where a cert is issued and send back to the TPS.  It is then imported into the token using the following command:

certutil -A -d /var/lib/rhpki-ca/alias -h lunasa2-ca   -n "Server-Cert seraph cert-pki-ca alee 0728 manualtest" -t "u,u,u" -a -i /root/mytest2/cert.txt

This command is the one that fails.  Specifically, it fails in devtoken.c when the C_CreateObject() command is called, with a error return code of 0x13 - CKA_INVALID_ATTRIBUTE_VALUE.

The stack trace at that point is as follows:

#0  import_object (tok=0x8c1ade0, sessionOpt=<value optimized out>,
    objectTemplate=0xbfa8eb38, otsize=9) at devtoken.c:252
#1  0x05262509 in nssToken_ImportCertificate (tok=0x8c1ade0, sessionOpt=0x0,
    certType=NSSCertificateType_PKIX, id=0x8c2e270,
    nickname=0x8a7a490 "Server-Cert seraph cert-pki-ca alee 0728 manualtest",
    encoding=0x8c2e278, issuer=0x8c2e280, subject=0x8c2e288, serial=0x8c2e290,
    email=0x0, asTokenObject=1) at devtoken.c:579
#2  0x052221f4 in PK11_ImportCert (slot=<value optimized out>,
    cert=<value optimized out>, key=<value optimized out>,
    nickname=<value optimized out>, includeTrust=Could not find the frame base for "PK11_ImportCert".
) at pk11cert.c:911
#3  0x08050f99 in AddCert (slot=0x8c28bc0, handle=0x8a9e240,
    name=0x8a7a490 "Server-Cert seraph cert-pki-ca alee 0728 manualtest",
    trusts=0xbfa8fbdb "u,u,u", inFile=0x8a7a450, ascii=1, emailcert=0,
    pwdata=0xbfa8ee78) at certutil.c:180
#4  0x08055082 in certutil_main (argc=<value optimized out>,
    argv=<value optimized out>, initialize=1) at certutil.c:2846
#5  0x08056083 in main (argc=Cannot access memory at address 0x1
) at certutil.c:2981

Note: The root cause of the failure has been isolated to changes that have occurred in nss or nss_tools between versions 3.12.2.0-4 (where it works) and 3.12.3.99-1.2 (where it doesn't)

We were able to go from a system where the certutil -A command above worked to one where it fails, simply by upgrading nss, nss-tools and nspr.

Ok - so on looking at the differences between the two sets of code, the problem is apparent.

Consider the following snippet from certutil.c (in the function AddCert())

This is what it used to look like:

        if (PK11_IsFIPS() || !PK11_IsInternal(slot)) {
            rv = PK11_Authenticate(slot, PR_TRUE, pwdata);
            if (rv != SECSuccess) {
                SECU_PrintError(progName, "could not authenticate to token %s.",
                                PK11_GetTokenName(slot));
                GEN_BREAK(SECFailure);
            }
        }

        rv =  PK11_ImportCert(slot, cert, CK_INVALID_HANDLE, name, PR_FALSE);
        if (rv != SECSuccess) {
            SECU_PrintError(progName, "could not add certificate to token or database");
            GEN_BREAK(SECFailure);
        }

In this case, we authenticate to the token and then attempt to import the cert.

This is how it looks now:

        rv =  PK11_ImportCert(slot, cert, CK_INVALID_HANDLE, name, PR_FALSE);
        if (rv != SECSuccess) {
            /* sigh, PK11_Import Cert and CERT_ChangeCertTrust should have
             * been coded to take a password arg. */
            if (PORT_GetError() == SEC_ERROR_TOKEN_NOT_LOGGED_IN) {
                rv = PK11_Authenticate(slot, PR_TRUE, pwdata);
                if (rv != SECSuccess) {
                    SECU_PrintError(progName,
                                "could not authenticate to token %s.",
                                PK11_GetTokenName(slot));
                    GEN_BREAK(SECFailure);
                }
                rv = PK11_ImportCert(slot, cert, CK_INVALID_HANDLE,
                                     name, PR_FALSE);
            }
            if (rv != SECSuccess) {
                SECU_PrintError(progName,
                        "could not add certificate to token or database");
                GEN_BREAK(SECFailure);
            }
        }

Here - we attempt an import and when that fails - if the return code is SEC_ERROR_NOT_LOGGED_IN, then we authenticate and retry the PK11_Import_Cert.  This obviously works for nethsm2k.

But lunasa returns a different error - ie. not SEC_ERROR_NOT_LOGGED_IN - so we do not authenticate to the token and retry the import.  We need to check if lunasa is not complying to the spec by not returning this error - but in any case, certutil with lunasa is now broken.

running certutil under gdb confirms this broken flow.

So Luna does not return SEC_ERROR_NOT_LOGGED_IN as NSS expects, then the question is what is the value of the code that Luna returns?

FYI - I tried a modified NSS where the token is logged into just prior to the PK11_ImportCert call (ie. putting back the old code).

With this code, certutil -A is successful against the lunasa.

********************

--- ./mozilla/security/nss/cmd/certutil/certutil.c.ade  2009-08-13 03:13:13.000000000 -0700
+++ ./mozilla/security/nss/cmd/certutil/certutil.c      2009-08-13 03:14:17.000000000 -0700
@@ -177,6 +177,16 @@ AddCert(PK11SlotInfo *slot, CERTCertDBHa
            GEN_BREAK(SECFailure);
        }

+        if (PK11_IsFIPS() || !PK11_IsInternal(slot)) {
+            rv = PK11_Authenticate(slot, PR_TRUE, pwdata);
+            if (rv != SECSuccess) {
+                SECU_PrintError(progName, "could not authenticate to token %s.",
+                                PK11_GetTokenName(slot));
+                GEN_BREAK(SECFailure);
+            }
+        }
+
+
        rv =  PK11_ImportCert(slot, cert, CK_INVALID_HANDLE, name, PR_FALSE);
        if (rv != SECSuccess) {
            /* sigh, PK11_Import Cert and CERT_ChangeCertTrust should have

So - looking closely at the NSS code, I see the following:

We expect the call to PK11_ImportCert to return either SEC_ERROR_TOKEN_NOT_LOGGED_IN or SEC_ERROR_ADDING_CERT

because at the end of PK11_Import, we have the following code:

loser:
    CERT_MapStanError();
    SECITEM_FreeItem(keyID,PR_TRUE);
    if (PORT_GetError() != SEC_ERROR_TOKEN_NOT_LOGGED_IN) {
        PORT_SetError(SEC_ERROR_ADDING_CERT);
    }
    return SECFailure;

This means we should look at all the cases where PK11_Import can end up in loser:
There are a number of places where this can happen - but none of these result in the return code that maps to SEC_ERROR_TOKEN_NOT_LOGGED_IN

The only place this can occur is at:
 
certobj = nssToken_ImportCertificate(token, NULL,
                                         NSSCertificateType_PKIX,
                                         &c->id,
                                         nickname,
                                         &c->encoding,
                                         &c->issuer,
                                         &c->subject,
                                         &c->serial,
                                         emailAddr,
                                         PR_TRUE);

which calls  :

 ckrv = CKAPI(epv)->C_CreateObject(session->handle,
                                      objectTemplate, otsize,
                                      &handle);

followed by:

    if (ckrv == CKR_OK) {
        object = nssCryptokiObject_Create(tok, session, handle);
    } else {
        nss_SetError(ckrv);
        nss_SetError(NSS_ERROR_PKCS11);
    }

We expect the token to return CKR_USER_NOT_LOGGED_IN when it returns 
CKR_ATTRIBUTE_VALUE_INVALID instead.

We need to figure out why this is - but I'm presuming that if more than one problem is apparent - ie. not logged in and also bad data - then the behaviour expected of the vendor is undefined ..

One more comment: To reproduce the bug under gdb, do the following:

1. Enter gdb by typing gdb
2. Enter the following in gdb:

   file /usr/bin/certutil

   set args -A -d /var/lib/pki-ca/alias -h lunasa2-ca   -n "Server-Cert
seraph cert-pki-ca alee 0728 manualtest 9" -t "u,u,u" -a
-i /root/mytest/cert.txt

  (the above is all one line)

3. set break points .. the ones most useful to me have been :

   b certutil.c:179 (where the certutil code change is made)
   b pk11cert.c:911 (just before the attribute struct is constructed)
   b  devtoken.c:248 (where the object is created.  If you step forward 
      here, you can query the value of ckrv, which is 19 -- 0x13 --   
      invalid_attribute_value)

I talked to alee on aim about this issue: here's the summary:

The template looks good. 

1) It seems that the Luna is seeing CKA_TOKEN set to PR_TRUE, but the user isn't logged in, so it's returning 'CKR_ATTRIBUTE_VALUE_INVALID' when it should really return 'CKR_USER_NOT_LOGGED_IN'. We should notify luna of this problem.

2) We can work around the problem by adding an option to certutil to force authentication on any certutil command. That allows us to handle misbehaving tokens if we need to.

Alee is working on a patch which I will review for upstream.

bob