IBM HTTP Server and SSL Signature Algorithms

So, whilst listening to this week's SecurityNow podcast, Episode 473 Google vs. SHA-1, I learned that Google plans to force the web to deprecate the SHA1 ( Secure Hash Algorithm ) from November 2014 even though Microsoft has a more moderate plan to move away from it by late 2017.

Google wants us to move to SHA2, aka SHA224 / SHA256 / SHA512, even though their own websites are still using SHA1 at the moment: -

Apparently, Google Chrome will start to provide visual feedback to end-users when they visit a site using SHA1, which has led to a bit of debate :-)

This led me to think about IBM HTTP Server, which I use and love on an almost daily basis.

I've created a lot of certificates in IHS using the IBM Global Security Toolkit ( GSK ), using syntax such as: -

/opt/IBM/HTTPServer/bin/gskcapicmd -cert -create -db /opt/IBM/HTTPServer/ssl/keystore.kdb -pw passw0rd -size 2048 -dn "cn=bam8012.uk.ibm.com\\,o=ibm\\,c=us\\" -label "bam8012.uk.ibm.com" -default_cert yes

I was interested to see what hashing algorithm IHS uses by default.

Here's the answer: -

/opt/IBM/HTTPServer/bin/gskcapicmd -cert -list -db /opt/IBM/HTTPServer/ssl/keystore.kdb -pw passw0rd

Certificates found
* default, - personal, ! trusted
*- bam8012.uk.ibm.com

/opt/IBM/HTTPServer/bin/gskcapicmd -cert -details -db /opt/IBM/HTTPServer/ssl/keystore.kdb -pw passw0rd -label bam8012.uk.ibm.com

Label : bam8012.uk.ibm.com
Key Size : 2048
Version : X509 V3
Serial : 1f75f58469abb054
Issuer : CN=bam8012.uk.ibm.com\,o\=ibm\,c\=us
Subject : CN=bam8012.uk.ibm.com\,o\=ibm\,c\=us
Not Before : 29 August 2014 18:03:07 GMT+01:00
Not After : 30 August 2015 18:03:07 GMT+01:00
Public Key
    30 82 01 22 30 0D 06 09 2A 86 48 86 F7 0D 01 01
    01 05 00 03 82 01 0F 00 30 82 01 0A 02 82 01 01
    00 CB CB F2 27 8F 1B 50 E3 A4 9C D9 D4 4E BE 2E
    87 95 FC FF D3 23 01 39 7F 9B 11 1F 9F 91 4F 19
    61 3F 1E 2B B5 79 01 2B 04 A0 91 1F DF 68 22 85
    88 B4 76 B9 B9 FD 68 A0 D7 90 06 50 8E FA 0B 52
    96 14 A6 F3 A0 94 4C 63 41 04 89 F0 F5 0F 6E E0
    7E A4 A2 C9 AB 59 D1 0A 92 31 9D 20 A0 F5 A3 C6
    22 04 1E 30 71 7C D8 5D 86 82 D0 B9 91 8F 9F A3
    E2 FA 41 7D 57 06 FE 2C 5E 1F 9B 6F 77 18 25 22
    60 DE E8 84 59 CF E5 0E E4 90 5E 5F F8 A7 45 B9
    77 67 1C 3E CC 21 45 76 79 04 F5 2B D7 CA 86 1F
    95 3F D7 14 2A 90 21 25 AC 23 34 A2 05 99 DE 46
    C2 6A 19 BF 79 E3 EC 7C F8 BE C7 A1 DE EA 38 6B
    80 7C 92 21 38 5B 11 9B 7B E6 23 05 57 AD F8 68
    DA 21 3B 6D 2A FA 80 47 4D F4 1F 8F A0 FB 38 99
    0D D9 C9 B6 32 67 A5 E4 3F B4 11 E6 4C 98 4C 76
    FB BB 37 ED ED FC 9D 6F 23 D1 0D 7C 95 D3 B1 E9
    EF 02 03 01 00 01
Public Key Type : RSA (1.2.840.113549.1.1.1)
Fingerprint : SHA1 : 
    EA F8 A8 80 AC F6 86 29 66 48 A8 9F C2 73 23 99
    68 E8 3C 7D
Fingerprint : MD5 : 
    5A 7F 67 55 D7 0F D1 08 37 FE 6F 31 47 F9 DE F5
Fingerprint : SHA256 : 
    2B 05 82 F8 41 7E 9C 10 4B AE A8 99 18 DD 1D 7B
    50 56 F7 C6 16 5F A9 3F CE 07 19 A3 06 6F 13 24
Signature Algorithm : SHA1WithRSASignature (1.2.840.113549.1.1.5)
Value
    88 3C 06 C5 DB FC A2 6C D4 C0 42 F4 1F A7 5D DF
    B7 FF B8 70 81 61 90 F5 D9 91 C4 9B E0 16 6A 61
    6C E5 55 C7 63 7E 9C 6A 05 6E C9 42 5C FA 26 4A
    6F 76 6F C5 6F 6E E5 E2 A4 65 8C BB 02 B1 A6 C4
    28 83 37 F1 39 BC 24 D1 9D 7F F2 66 95 5F 90 8E
    45 8E 97 95 61 89 C3 70 69 35 DC 2A CD FE E8 0A
    1A 8B 19 15 A3 DF BB 17 A5 A2 84 09 4F 32 12 47
    46 9D A4 16 F9 B4 E0 73 10 35 0B 0B AB EC 55 59
    00 DD F7 DA B7 44 DE 52 AB BE B3 B3 F5 40 5F 75
    FB 43 8E 4A FA 65 81 99 BB 97 7F DE 9B 88 8B ED
    11 14 FB 34 0B 15 6C EC 33 88 6F FB 41 AF 16 B0
    45 7A 41 2D 3C E4 B3 0B C8 56 81 B2 06 C9 C1 71
    D6 26 71 5C 13 61 39 B6 DD 97 8D 0D F4 84 34 9F
    3D F1 8B C2 E0 F8 11 2F 88 82 60 1B 50 A5 C0 97
    B0 5A 92 8B 1B DE D1 6A D3 BD 7B DC 7E AD 7A 2A
    EA DB 32 E3 14 95 69 94 9A D5 1B C2 A5 14 8F 7E
Trust Status : Enabled

So there's the answer, IHS generates a SHA1 certificate by default. I checked this for IHS 8.0 and 8.5, and the same is true in both cases.

Now that makes sense, given most of the world is still supporting SHA1 and, apparently, MS Windows XP SP2 doesn't support SHA2 - although I'd hope that any remaining Windows XP users would've moved to SP3 a looooong time ago; perhaps embedded Windows users don't have that luxury ?

Anyway, I then wondered whether I could've chosen to generate a SHA2 certificate using gskcapicmd. Guess what, I can :-)

Here's the multitude of choices: -

-Command usage-
-db | -crypto         Required
-tokenlabel           Required if -crypto present
-label                Required
-pw                   Optional
-dn                   Required
-type                 Optional if -db present <cms | kdb>
-expire               Optional
-size                 Optional
-x509version          Optional <1 | 2 | 3>
-default_cert         Optional <yes | no>
-ca                   Optional <true | false>
-sig_alg | -sigalg    Optional < | md5 | MD5_WITH_RSA | MD5WithRSA | sha1 | SHA_WITH_RSA | SHAWithRSA | SHA1WithRSA | sha224 | SHA224_WITH_RSA | SHA224WithRSA | sha256 | SHA256_WITH_RSA | SHA256WithRSA | SHA2WithRSA | sha384 | SHA384_WITH_RSA | SHA384WithRSA | SHA3WithRSA | sha512 | SHA512_WITH_RSA | SHA512WithRSA | SHA5WithRSA | SHA1WithECDSA | EC_ecdsa_with_SHA1 | SHA224WithECDSA | EC_ecdsa_with_SHA224 | SHA256WithECDSA | EC_ecdsa_with_SHA256 | SHA384WithECDSA | EC_ecdsa_with_SHA384 | SHA512WithECDSA | EC_ecdsa_with_SHA512>
-ca_label             Optional
-san_dnsname          Optional
-san_emailaddr        Optional
-san_ipaddr           Optional
-certpolicy           Optional
-eku                  Optional <ocspSigning, timeStamping, emailProtection, codeSigning, clientAuth, serverAuth, SSLStepUpApproval, any>
-ku                   Optional <digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment, keyAgreement, keyCertSign, cRLSign, encipherOnly, decipherOnly>
-template             Optional
-secondarydb          Optional if -crypto present
-secondarydbpw        Optional if -secondarydb present
-secondarydbtype      Optional if -secondarydb present

That's a LOT of choice :-)

Of course, one would need to think about the consuming devices BEFORE moving to SHA2, even though Google appear to be telling the rest of the internet what to do .....

Bottom line, think about the Signature Algorithm when creating certificates, along with everything else :-)