Tuesday, 31 May 2016

IBM HTTP Server, Global Security Toolkit and CTGSK3039W

I have written about this before: -



but I continue to learn.

This time around, I'm trying to create a Certificate Request using a different Signature Algorithm, SHA256WithECDSA, as follows: -

/opt/IBM/HTTPServer/bin/gskcapicmd -certreq -create -db /opt/IBM/HTTPServer/ssl/keystore.kdb -pw passw0rd -label bpm856.uk.ibm.com -dn cn=bpm856.uk.ibm.com,dc=uk,dc=ibm,dc=com -file /home/wasadmin/bpm856.uk.ibm.com_ihs.req -size 2048 -sigalg SHA256WithECDSA -san_dnsname bpm856.uk.ibm.com

but I see this: -

CTGSK3039W Certificate request "bpm856.uk.ibm.com" could not be created.

I added a trace string to my command: -

/opt/IBM/HTTPServer/bin/gskcapicmd -certreq -create -db /opt/IBM/HTTPServer/ssl/keystore.kdb -pw passw0rd -label bpm856.uk.ibm.com -dn cn=bpm856.uk.ibm.com,dc=uk,dc=ibm,dc=com -file /home/wasadmin/bpm856.uk.ibm.com_ihs.req -size 2048 -sigalg SHA256WithECDSA -san_dnsname bpm856.uk.ibm.com -trace foobar.trc

I don't know precisely how to view the resulting trace file, but I was able to view it using view : -

Ngskkmmutex.cpp^@^@^@µ^@^@^@aGSKKM_RequestMutex(int mutexNum)^@0020465245440001574DEC020247001030303030374637443442303645373230^@^@^@<80>WMì^B^@^@<96>_^@^@^@^A@^@^@^@^@^@^@^D^@^@^@^@^@^@^@^@^@^@^@aGSKKM_RequestMutex(int mutexNum)^@0020465245440001574DEC020247001030303030374637443442303645373230^@^@^@<80>WMì^B^@^@<96>_^@^@^@^A^@^@^@^A^@^@^@^C^@^@^@^Kgskkmdb.cpp^@^@^@·^@^@^@rERROR: sizeof(GSKKM_DB_HANDLE) < sizeof(aDBEntry)^@0020465245440001574DEC020247001030303030374637443442303645373230^@^@^@<80>WMì^B^@^@<96>_^@^@^@^A<80>^@^@^@^@^@^@^D^@^@^@^Lgskkmapi.cpp^@^@"º^@^@^@OGSKKM_Strdup()^@0020465245440001574DEC020247001030303030374637443442303645373230^@^@^@<80>WMì^B^@^@<96>_^@^@^@^A@^@^@^@^@^@^@^D^@^@^@^@^@^@^@^@^@^@^@OGSKKM_Strdup()^@0020465245440001574DEC020247001030303030374637443442303645373230^@^@^@<80>WMì^B^@^@<96>_^@^@^@^A<80>^@^@^@^@^@^@^D^@^@^@^Lgskkmapi.cpp^@^@"º^@^@^@OGSKKM_Strdup()^@0020465245440001574DEC020247001030303030374637443442303645373230^@^@^@<80>WMì^B^@^@<96>_^@^@^@^A@^@^@^@^@^@^@^D^@^@^@^@^@^@^@^@^@^@^@OGSKKM_Strdup()^@0020465245440001574DEC020247001030303030374637443442303645373230^@^@^@<80>WMì^B^@^@<96>_^@^@^@^A<80>^@^@^@^@^@^@^D^@^@^@^Lgskkmapi.cpp^@^@"º^@^@^@OGSKKM_Strdup()^@0020465245440001574DEC020247001030303030374637443442303645373230

Working on the assumption that there MIGHT be a problem with the Key Size ( which I'd specified as 2048 bits, I made an assumption that 2048 may be too big for that particular Signature Algorithm.

I tested my hypothesis by switching to a 512-bit key: -

/opt/IBM/HTTPServer/bin/gskcapicmd -certreq -create -db /opt/IBM/HTTPServer/ssl/keystore.kdb -pw passw0rd -label bpm856.uk.ibm.com -dn cn=bpm856.uk.ibm.com,dc=uk,dc=ibm,dc=com -file /home/wasadmin/bpm856.uk.ibm.com_ihs.req -size 512 -sigalg SHA256WithECDSA -san_dnsname bpm856.uk.ibm.com

which worked a treat.

I validated the Certificate Request thusly: -

openssl req -in bpm856.uk.ibm.com_ihs.req -text -noout

Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: DC=com, DC=ibm, DC=uk, CN=bpm856.uk.ibm.com
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (521 bit)
                pub: 
                    04:01:05:be:47:ad:3f:81:aa:fe:95:21:ba:5c:5f:
                    8a:e7:37:ba:8c:80:2d:d1:73:e9:ff:00:7c:e0:f1:
                    0d:46:3a:4c:84:b1:27:63:32:99:2c:33:f1:35:66:
                    22:5d:f2:9d:7e:f1:54:70:f8:d8:f6:f0:90:cc:4d:
                    a8:41:a8:7a:9e:65:96:01:f0:fe:68:63:6d:55:34:
                    ce:d7:ad:20:a3:e0:3f:1c:af:4b:25:84:30:4f:5d:
                    06:d5:86:60:d1:51:bd:65:77:bd:07:08:49:c4:dd:
                    1b:23:83:73:a2:ab:11:6b:3d:e8:4e:17:6b:c7:97:
                    a0:56:86:05:88:72:dc:0c:81:11:78:8e:1c
                ASN1 OID: secp521r1
        Attributes:
        Requested Extensions:
            X509v3 Subject Alternative Name: 
                DNS:bpm856.uk.ibm.com
    Signature Algorithm: ecdsa-with-SHA256
         30:81:88:02:42:00:8c:2b:3c:b5:5d:65:2e:68:92:e9:38:8e:
         01:e2:01:5c:9b:81:12:ae:d7:57:fc:bf:bb:0e:fa:07:da:4f:
         ea:f4:da:4e:47:5a:37:99:4c:6f:70:44:af:90:db:ac:0b:6b:
         7a:14:7b:57:ce:d4:be:81:c8:66:4a:40:79:03:9d:8e:6f:02:
         42:01:9d:65:ba:29:2f:84:f8:18:ca:c1:6c:e5:c7:f5:99:3b:
         aa:53:04:3f:47:3b:1f:fa:3a:cd:fa:57:42:c7:0c:81:63:ec:
         67:0c:b0:96:7e:3e:c2:76:f6:12:f8:72:e9:99:21:38:52:df:
         a4:42:1a:36:e1:17:fb:74:3a:da:34:11:d9


which is nice.

No comments:

Note to self - use kubectl to query images in a pod or deployment

In both cases, we use JSON ... For a deployment, we can do this: - kubectl get deployment foobar --namespace snafu --output jsonpath="{...