Non-Verisign certs in WS7
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
[1125 byte] By [
wgkorba] at [2007-11-26 17:40:12]
# 1
Interesting. It should certainly list all available valid certificates.Can you confirm that these certificates work correctly if you manually refer to them in server.xml?Does certutil -L correctly list all the certificates?
jyria at 2007-7-9 0:08:21 >
# 2
Well, this is weird. I migrated a server that was using one of my NetSol certs from the crypto accelerator, and that instance starts fine, even though the certificate that it is using is not shown on the SSL configuration tab.
However, when I copy essentially the same information from the migrated, working server into a server instance that I configured by hand, it cannot find the certificate. Hmmm...OK, that's because I had the hand-configured server set to 64-bit mode. When I change it to 32-bit mode, it starts up OK. When I point my browser at my site and view the certificate, it is indeed my NetSol cert. So that's another question: why does the NetSol cert not work when the server is in 64-bit mode?
And certutil -L shows the certs, yes.
Bill
# 3
Bill, you have mentioned in your first post that the NetSol certs are CAs.Are all the NetSol certs are CAs?If so, then it explains the behaviour that you are observing.Only, non-CA owned certificates will be listed.
# 4
No, I have NetSol server certificates issued by a NetSol CA. In addition to the server certificate, when the cert was issued they sent me three CA certs (one "trusted CA" and two "certificate chain" certs) that I needed to install since those are not included in all servers in the marketplace. The actual server certificate itself is installed, as I said, in a slot in my Sun Crypto Accelerator, and is being used to secure other servers (specifically, AS7 and WS6.x).
I currently have the server running with the NetSol certificate after manually updating the server.xml. You can point your browser at the following URL to see that it is a valid cert (and indeed, that the server is able to use it at start-up):
https://www.qisc.com/test.txt
Thanks,
Bill
# 5
Ok.Could you give the output of certutil -L -h "hardware_token_name"?Also, could you paste the output of bin/wadm list-certs --config=<config_name> --token=<hardware_token_name>?Thanks.
# 6
Output of wadm list-certs --verbose -all:
nicknameissuer-nameexpiry-date
--
admin@qisc.com:Server-CertNetwork Solutions Certificate Authority May 19, 2007 6:59:59 PM
There 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 admin@qisc.com:Server-Cert
Enter Password or Pin for "NSS Certificate DB":
Enter Password or Pin for "admin@qisc.com":
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 Corporationc,,
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-Certu,u,u
Admin-Client-Certu,u,u
AddTrust External RootCT,C,C
UTN-USERFirst-Hardware - AddTrust AB c,,
Network Solutions Certificate Authority - GTE Corporationc,,
Admin-CA-CertCTu,u,u
However, 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
# 7
With respect to your 32bit vs. 64bit comment:
Run "modutil -dbdir . -list" from the config directory (or elsewhere, setting dbdir as needed). Since there is an external token there will be some module listed here which provides the interface to that token. The "library name" points to the appropriate .so file. Since this is either a 32bit or a 64bit .so, it'll only work in the corresponding scenario.Check with modutil on your instances to see which .so is referenced.
jyria at 2007-7-9 0:08:21 >
# 8
Ah yes, excellent point. Sure enough, that was the case. I just did a modutil -delete to remove the 32-bit module, then loaded the sparcv9 module in its place:
/opt/sjsws7/bin/sparcv9/modutil -dbdir . -nocertdb -force \
-add 'Sun Crypto Accelerator' \
-libfile /opt/SUNWconn/crypto/lib/sparcv9/libpkcs11.so \
-mechanisms RSA:DSA:RC4:DES
Lo and behold, I reloaded the server config, flipped to 64-bit, restarted it, and now it is able to find the certificates in the CA100 just fine when starting the server.
However, this seems to have made things worse in the admin server. Now when I go to the SSL page, it says "SSL cannot be enabled as there are no certificates available". Perhaps the admin server is running in 32-bit mode, and it cannot use the 64-bit SO that I just loaded into the secmod.db for my server?
OK, I just switched back to 32-bit mode so we're not trying to hit a moving target here. ;-)
Too bad I can't have both "secmod.db" and "secmod64.db" or something like that to support both depending on which mode I'm running the server in. OTOH, I guess I should just pick 32 or 64 and just stick with it.
In any case, I'd still like to get my certs working through the admin interface.
Thanks,
Bill
# 9
Anybody else have any ideas on this? If not, I guess I'll have to open a support request with Sun.Thanks,Bill
# 10
Can you confirm that even when all instances (including admin-server) are running as 32bit and the modules installed/listed via modutil are also 32bit, the problem still persists?
The server certificates are not being extensively validated by merely listing them so some of the points discussed earlier such as missing certs in validation chain should not prevent them from showing up. I don't know offhand what might be "special" about the certs which do not get listed. It certainly deserves investigation. If you open a support case the assigned engineer will be able to gather more detailed data than what is practical here.
jyria at 2007-7-9 0:08:21 >
# 11
Yes, that is where I am right now.Thanks,Bill
# 12
certutil certainly has a -h option.Please provide the output of the following command:$bin/certutil -L -d admin-server/config-store/configuration name/config -h "admin@qisc.com"
# 13
Also did you have to provide the password while executing list-certs?
# 14
637# certutil -L -d www.qisc.com/config -h 'admin@qisc.com'
Enter Password or Pin for "admin@qisc.com":
admin@qisc.com:Server-Certu,u,u
wadm> list-certs --all --token=admin@qisc.com --config=www.qisc.com
Please enter token-pin>
admin@qisc.com:Server-CertNetwork Solutions Certificate Authority May 19, 2007 6:59:59 PM
Thanks,
Bill
# 15
OK...Try this on the Administration GUI.
Assume that you have the h/w token with the NetSol certificates and everything and you are about to enable SSL on a http-listener.
Now, before you edit the http-listener goto Configurations->configname->Certificates page.
You will see a "Set Passwords" button.
If it is enabled, click on it and enter the password in the password field corresponding to the h/w token.
And then proceed to editing the http-listener.
Check if the NetSol certificate is listed.
# 16
OK, I set the passwords and the admin gui said "Password(s) set in session successfully." All of the available certs were then listed on the Certificates tab.
Next, I went to the HTTP Listeners tab, clicked on one of my existing listeners to open the edit window, and therein clicked on the SSL tab. The only certs listed in the "RSA Certificates" select-list are the Verisign certs (which, as is the case with my NetSol certs. are stored in my Crypto Accelerator tokens).
This is exactly what I've been seeing all along.
Thanks,
Bill
# 17
Could you provide a screenshot of the http-listener edit dialog where it is only listing the Verisign certs?Thanks.
# 18
You can see a screen shot of the certificates tab here: http://www.qisc.com/tmp/certs-list.jpgand a screen shot of the abbreviated select-list here: http://www.qisc.com/tmp/cert-select-list.jpgThanks,Bill
# 19
Also could you give the output of the following command:wadm> get-cert-prop --token=admin@qisc.com --config=www.qisc.com --nickname=admin@qisc.com:Server-Cert
# 20
wadm> get-cert-prop --token=admin@qisc.com --config=www.qisc.com --nickname=admin@qisc.com:Server-Cert
Please enter token-pin>
nickname=admin@qisc.com:Server-Cert
expiry-date=May 19, 2007 6:59:59 PM
is-self-signed=false
is-read-only=false
O="Quixote Internet Services & Consulting, Inc."
CN=*.qisc.com
OU=Secure Link SSL Wildcard
issuer-name=Network Solutions Certificate Authority
issue-date=May 18, 2006 7:00:00 PM
is-ca-cert=false
has-crl=false
C=US
token=admin@qisc.com
L=Chippewa Falls
is-user-cert=true
ST=Wisconsin
is-expired=false
serial-number=28:F5:87:82:B0:65:FF:58:08:63:B5:0E:69:07:EA:6D
issuer=CN=Network Solutions Certificate Authority,O=Network Solutions L.L.C.,C=US
subject=CN=*.qisc.com,OU=Secure Link SSL Wildcard,O="Quixote Internet Services & Consulting, Inc.",L=Chippewa Falls,ST=Wisconsin,C=US
fingerprint=73:02:F5:C2:53:C2:47:46:14:1D:15:FC:0C:89:5E:8E
Thanks,
Bill
# 21
I have found the problem and I have raised a bug for it.
But I have not found the extent of the problem.
Could you help me by providing the following data?
1. Have you installed these certificates in the h/w token via the WS 6.0 or WS 7.0 administration interfaces?
2. Could you tell me what h/w token accelerator are you using for the tokens "admin@qisc.com" and "nobody@schoolidentity"? It would help me if you can be very elaborate about this information.
3. Could you give me the output of get-cert-prop for the certificates "nobody@netstarnetwork:Server-Cert" and "nobody@schoolidentity:Server-Cert"?
4. Would it be possible for you to generate a certificate request from the token "admin@qisc.com", get it signed by any CA (verisign allows free test certificates), install it to "admin@qisc.com" and run get-cert-prop on that certificate? The output of these series of commands would be most useful.
Thanks.
# 22
Ah, good, I'm not crazy after all. ;-)
Answers to your questions:
1. I don't recall exactly - I certainly did not use ws7 as I just installed that two weeks ago. I either used the App Server 7 admin server or I may have used certutil and/or pk12util to install the certs in the h/w token.
2. The h/w token is a Sun Crypto Accelerator 100 daughter card in a V240. I am running the highest release level of the CA100 software that works on Solaris 9 (I looked at the newer version when it was announced last year, but it required that I first upgrade to Solaris 10, and I'm not ready for that yet). If you want the output of "showrev -p" or something, let me know (you can e-mail me for out-of-band information like that so as not to clutter up the forums).
3. Here ya go:
wadm> get-cert-prop --token=nobody@nexstarnetwork --config=nexstarnetwork.com --nickname=nobody@nexstarnetwork:Server-Cert
Please enter token-pin>
nickname=nobody@nexstarnetwork:Server-Cert
expiry-date=Jan 14, 2009 5:59:59 PM
is-self-signed=false
is-read-only=false
O="Nexstar, Inc."
CN=www.nexstarnetwork.com
OU=Secure Link SSL Pro
issuer-name=Network Solutions Certificate Authority
issue-date=Jan 14, 2007 6:00:00 PM
is-ca-cert=false
has-crl=false
C=US
token=nobody@nexstarnetwork
L=White Bear Lake
is-user-cert=true
ST=Minnesota
is-expired=false
serial-number=53:60:C3:6B:1C:D3:80:AA:6C:C8:F9:01:71:2E:33:EA
issuer=CN=Network Solutions Certificate Authority,O=Network Solutions L.L.C.,C=US
subject=CN=www.nexstarnetwork.com,OU=Secure Link SSL Pro,O="Nexstar, Inc.",L=White Bear Lake,ST=Minnesota,C=US
fingerprint=7D:BA:BC:72:3D:7E:C9:F1:3D:9C:18:71:5D:E1:8F:D4
wadm> get-cert-prop --token=nobody@schoolidentity --config=www.qisc.com --nickname=nobody@schoolidentity:Server-Cert
Please enter token-pin>
nickname=nobody@schoolidentity:Server-Cert
expiry-date=Sep 29, 2007 6:59:59 PM
is-self-signed=false
is-read-only=false
O=ChalkTalk Business Promotions
CN=www.schoolidentity.com
OU=Secure Link SSL Pro
issuer-name=Network Solutions Certificate Authority
issue-date=Sep 28, 2006 7:00:00 PM
is-ca-cert=false
has-crl=false
C=US
token=nobody@schoolidentity
L=Shoreview
is-user-cert=true
ST=Minnesota
is-expired=false
serial-number=77:3A:96:F9:50:97:22:3A:24:48:45:1C:43:E1:71:62
issuer=CN=Network Solutions Certificate Authority,O=Network Solutions L.L.C.,C=US
subject=CN=www.schoolidentity.com,OU=Secure Link SSL Pro,O=ChalkTalk Business Promotions,L=Shoreview,ST=Minnesota,C=US
fingerprint=99:34:7B:E9:F5:24:94:6E:24:E4:2C:40:8C:37:FF:B5
4. Would it be adequate for me to sign my own CSR, or do you need me to go through a real CA?
Thanks,
Bill
# 23
It's OK if you sign your own CSR. Just make sure it's not a self-signed certificate.Thanks for the info. But the output of install-certificate is what would be most useful.
# 24
OK, here's the sequence of events whereby I generated a CSR, signed it, and installed it.
First, I installed my CA cert in the instance's internal key database.
wadm> install-cert --verbose --config=dev-ws7.qisc.com --cert-type=ca --nickname="QISC CA" /tmp/certs/ca-cert.pem
CLI201 Command 'install-cert' ran successfully
Next, I generated the CSR:
wadm> create-cert-request --key-type=rsa --org="QISC, Inc." --locality="Chippewa Falls" --state="Wisconsin" --country="US" --config=dev-ws7.qisc.com --token=admin@qisc.com --server-name=dev-ws7.qisc.com
Please enter token-pin>
--BEGIN NEW CERTIFICATE REQUEST--
( I deleted this output, but it was a valid CSR )
--END NEW CERTIFICATE REQUEST--
Next, I used my CA cert to sign it:
openssl ca -batch -config openssl.cnf -days 3650 -in dev-ws7-20070216.csr -out dev-ws7-20070216.crt
Using configuration from openssl.cnf
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 19 (0x13)
Validity
Not Before: Feb 16 13:41:56 2007 GMT
Not After : Feb 13 13:41:56 2017 GMT
Subject:
countryName= US
stateOrProvinceName= Wisconsin
organizationName = QISC, Inc.
commonName= dev-ws7.qisc.com
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Key Identifier:
33:A4:C6:31:56:58:4B:16:0D:B7:41:56:EB:41:32:E0:56:BA:D4:83
X509v3 Authority Key Identifier:
keyid:A6:09:5B:C8:CF:7A:91:0C:30:12:9D:3F:1C:16:0A:82:0E:FB:39:F8
DirName:/CN=QISC CA/C=US/ST=Wisconsin/L=Chippewa Falls/O=qisc.com/emailAddress=korb@qisc.com
serial:89:69:36:CB:72:76:BF:8D
Netscape CA Revocation Url:
https://www.qisc.org/ca-crl.pem
Certificate is to be certified until Feb 13 13:41:56 2017 GMT (3650 days)
Write out database with 1 new entries
Data Base Updated
Next, I installed the cert and listed the properties:
wadm> install-cert --verbose --config=dev-ws7.qisc.com --token=admin@qisc.com --cert-type=server --nickname=dev-cert /tmp/certs/dev-ws7-20070216.crt
Please enter token-pin>
CLI201 Command 'install-cert' ran successfully
wadm> get-cert-prop --token=admin@qisc.com --config=dev-ws7.qisc.com --nickname=dev-cert
Please enter token-pin>
nickname=admin@qisc.com:dev-cert
expiry-date=Feb 13, 2017 7:41:56 AM
is-self-signed=false
is-read-only=false
O="QISC, Inc."
CN=dev-ws7.qisc.com
issuer-name=QISC CA
issue-date=Feb 16, 2007 7:41:56 AM
is-ca-cert=false
has-crl=false
C=US
token=admin@qisc.com
is-user-cert=true
ST=Wisconsin
is-expired=false
serial-number=13
issuer=E=korb@qisc.com,O=qisc.com,L=Chippewa Falls,ST=Wisconsin,C=US,CN=QISC CA
key-type=rsa
subject=CN=dev-ws7.qisc.com,O="QISC, Inc.",ST=Wisconsin,C=US
key-size=1024
fingerprint=5A:FA:F5:0E:DA:A2:0A:54:D2:39:F1:9D:30:61:6C:6E
I then went into the admin server gui, chose to edit and existing listener, and the new certificate does indeed show up in the list of available RSA certs.
I hope this helps. Let me know if you need anything else.
BTW, this spurs one more question. Every time I do something with one of my tokens, I am prompted for the token's PIN. However, when I started wadm, I specified the --password-file option and pointed at a file that has all of my passwords in it, including a line of the format "wadm_admin@qisc.com=MyTokenPassword". This leads to my question: Why is it that even though my password file included the token PIN, I still have to manually type it in?
Thanks,
Bill
