Non-Verisign certs in WS7

Question

Hello,
I have a mix of server certificates from Verisign and Network Solutions CAs. Both types are stored in my Crypto accelerator (hardware token), from where I've been using them for WS6 and AS7 instances.
In WS7, the Certificates tab in the admin interface shows certs of both types and the token that they are contained within. When I attempt to configure a listener with SSL enabled, the Certificate field has two types, "RSA Certificates" and "ECC Certificates". The latter says "No ECC Certificates Available", and the pick-list for the RSA Certificates only lists the Verisign certificates.
For a server that I migrated from an older version (WS6.1), the server.xml lists the correct server-cert-nickname value for a NetSol cert, and indeed, the cert is properly loaded and the listener starts up fine using that certificate.
Why is it that my NetSol certs don't show up in the admin interface? I can hack the server.xml file in vi to use the correct certs, but I'm thinking there should be a way that I can access these other certs with the admin interface.
Thanks,
Bill

Answer 1

Output of wadm list-certs --verbose -all:
nickname        issuer-name     expiry-date
[email protected]:Server-Cert      Network Solutions Certificate Authority May 19, 2007 6:59:59 PMThere is no -h option to certutil -L:
certutil -L [-n cert-name] [-X] [-d certdir] [-P dbprefix] [-r] [-a]However, if I export it from the hardware token using pk12util then import it into the internal token, I can view the details:
# pk12util -o xxx -d . -n [email protected]:Server-Cert  
Enter Password or Pin for "NSS Certificate DB":
Enter Password or Pin for "[email protected]":
Enter password for PKCS12 file:
Re-enter password:
pk12util: PKCS12 EXPORT SUCCESSFUL
# pk12util -i xxx -d $PWD
Enter Password or Pin for "NSS Certificate DB":
Enter password for PKCS12 file:
pk12util: PKCS12 IMPORT SUCCESSFUL
# certutil -L -d .   
Network Solutions Certificate Authority - GTE Corporation    c,, 
Server-Cert                                                  u,u,u
# certutil -L -d . -n Server-Cert
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            28:f5:87:82:b0:65:ff:58:08:63:b5:0e:69:07:ea:6d
        Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
        Issuer: "CN=Network Solutions Certificate Authority,O=Network Solutio
            ns L.L.C.,C=US"
        Validity:
            Not Before: Fri May 19 00:00:00 2006
            Not After : Sat May 19 23:59:59 2007
        Subject: "CN=*.qisc.com,OU=Secure Link SSL Wildcard,O="Quixote Intern
            et Services & Consulting, Inc.",L=Chippewa Falls,ST=Wisconsin,C=U
            S"
        Subject Public Key Info:
            Public Key Algorithm: PKCS #1 RSA Encryption
            RSA Public Key:
                Modulus:
                    c4:87:81:66:77:99:c5:8e:f1:59:ff:59:c6:38:63:5a:
                    46:31:8e:13:38:5e:2e:71:d7:22:38:5b:df:c4:47:e9:
                    d3:c3:ff:52:3a:5b:21:c1:b5:01:0a:ec:81:3d:80:b4:
                    39:74:6a:7d:39:63:e1:06:a4:f1:45:cf:43:8d:6a:79:
                    49:4e:d9:22:d2:8f:08:6e:23:87:e3:14:7f:aa:c7:8f:
                    df:d7:d0:e1:e0:7e:1c:d7:64:d0:43:94:19:06:7d:48:
                    82:6f:e3:e1:05:69:cc:42:67:9f:db:e5:c7:6e:11:7a:
                    10:94:6c:95:f0:1e:5c:36:93:37:09:ea:b4:0d:4e:6f
                Exponent: 65537 (0x10001)
(stuff deleted for brevity - let me know if you need to see all of this output)Hmmm...this is interesting...after importing the cert from the hardware token into the internal certificate database, it now shows up as "Server-Cert" in the RSA Certificates list of the SSL->Edit HTTP Listener admin page. So it only shows certs from the hardware token when they are Verisign certs, even though the NetSol certs work just fine when they are stored in the internal database. This is NOT a work-around, however, as this defeats the purpose of having the crypto accelerator.
BTW, I also sent a note to NetSol's support people, and they had this thought:
As we use an intermediate, that could be the reason why they are not listed.
Without the intermediate it will not find a chain to the trusted root.
We would recommend contacting the software provider for details on
importing the intermediate into the application server.I have already tried importing their certificates into the internal token, but that had no effect on this problem. Do I need to import their intermediate certs into the hardware token, rather than the internal one? If so, how do I do that? Or do I need to install these intermediate certs in the admin server's internal database, rather than my server instance's database?
On the assumption that these intermediate certs were needed in the admin server's internal database, I used certutil to load them to see if that would help:
# certutil -A -n 'AddTrust External Root' -t 'CT,C,C' \
-d . -a -i /tmp/certs/AddTrustExternalCARoot.crt
# certutil -A -n 'UTN-USERFirst-Hardware - AddTrust AB' -t 'c,,' \
-d . -a -i /tmp/certs/UTNAddTrustServer_CA.crt
# certutil -A -n 'Network Solutions Certificate Authority - GTE Corporation' -t 'c,,' \
-d . -a -i /tmp/certs/NetworkSolutions_CA.crt
# certutil -L -d .                                                                                     
Admin-Server-Cert                                            u,u,u
Admin-Client-Cert                                            u,u,u
AddTrust External Root                                       CT,C,C
UTN-USERFirst-Hardware - AddTrust AB                         c,, 
Network Solutions Certificate Authority - GTE Corporation    c,, 
Admin-CA-Cert                                                CTu,u,uHowever, after stopping and restarting the admin server, I still do not see my token-resident certs in the admin interface.
Let me know what you'd like to see next.
Thanks,
Bill