I recently got a new Asus RT-N66U Dark Knight. One of my main reasons for selecting this router was its ability to run the DD-WRT custom firmware. DD-WRT offers a host of cool features, among these is the ability to do web based administration on the router’s WAN interface. Basically you can fire up your favorite browser and log on to the web interface of the router from anywhere on the Internet. Of course you wouldn’t want to do that without encryption so the DD-WRT firmware comes with its own self signed SSL certificate. When trying to use this particular feature was when I started to have problems.
I navigated to my routers WAN address while on the Internet using Internet Explorer. I fully expected IE to throw an error regarding the certificate. The certificate in the router firmware was bound to be a generic certificate not containing either my WAN IP or my FQDN in its subject fields. IE lets you continue if there is a mismatch between what you have typed in your browser’s address field and what is specified in the certificate’s subject field. But instead IE gave me this:
As you can see the only option is to close the webpage. IE would not even let me see the certificate and look at the actual certificate error. At this point I switched to Google Chrome to see what it had to offer. This is what it said:
Chrome let me continue despite the certificate error and I could access the router’s web pages and also look at the certificate:
I exported the certificate and dumped it’s information with certutil.exe:
X509 Certificate:
Version: 1
Serial Number: f1509cfb65bfbb46
Signature Algorithm:
Algorithm ObjectId: 1.2.840.113549.1.1.5 sha1RSA
Algorithm Parameters:
05 00
Issuer:
E=info@dd-wrt.com
CN=NewMedia-NET GmbH
OU=DD-WRT
O=NewMedia-NET GmbH
L=Dresden
S=Saxon
C=DE
Name Hash(sha1): f03bcb463cb28f2c7a590ff0ea429861f2e974b1
Name Hash(md5): 3a7bd1dbec01065f788593f78810a3b5
NotBefore: 28.04.2013 05:46
NotAfter: 26.04.2023 05:46
Subject:
E=info@dd-wrt.com
CN=NewMedia-NET GmbH
OU=DD-WRT
O=NewMedia-NET GmbH
L=Dresden
S=Saxon
C=DE
Name Hash(sha1): f03bcb463cb28f2c7a590ff0ea429861f2e974b1
Name Hash(md5): 3a7bd1dbec01065f788593f78810a3b5
Public Key Algorithm:
Algorithm ObjectId: 1.2.840.113549.1.1.1 RSA (RSA_SIGN)
Algorithm Parameters:
05 00
Public Key Length: 512 bits
Public Key: UnusedBits = 0
0000 30 48 02 41 00 cf 8b 93 48 0c 3d b1 1e 77 bc 62
0010 0a b5 ac 2b 82 cc 10 1c f0 57 97 9e 17 bc af 82
0020 41 66 6c e1 c2 6b 26 72 0a ea 88 6a d6 7a 51 32
0030 e9 53 99 e6 1b ce 53 10 59 16 74 89 9c 09 a4 0c
0040 3c 9d 13 80 81 02 03 01 00 01
Certificate Extensions: 0
Signature Algorithm:
Algorithm ObjectId: 1.2.840.113549.1.1.5 sha1RSA
Algorithm Parameters:
05 00
Signature: UnusedBits=0
0000 e7 73 70 c1 62 c8 74 7d b8 25 66 e7 c7 99 94 cb
0010 8f db 52 82 66 24 d8 b8 3f 4e 3e 76 e3 2e 75 63
0020 af 3d d4 1c c7 4a 99 9d c4 07 72 cd d3 19 f2 3c
0030 4d 99 a5 15 87 b8 9e 2f 82 1f 15 5d 93 3a 76 94
Signature matches Public Key
Root Certificate: Subject matches Issuer
Key Id Hash(rfc-sha1): be a4 73 4e 2a 56 40 36 ff 3f 2c 0d 35 32 c3 10 a7 24 b2 2a
Key Id Hash(sha1): a8 7e 4f 69 e0 8c 94 49 13 1a 81 c3 64 32 25 2f 3a ab 85 85
Key Id Hash(md5): d98943eba0509d9518cb725cfddc2024
Key Id Hash(sha256): a42184530c87d0045e4c1c32fa7c2561de9d5d5de477bdd3731a0d858d877dc0
Cert Hash(md5): db c8 74 6a 22 3e d5 ad cf 3d d5 1a bd e0 e4 dc
Cert Hash(sha1): 60 50 8a 06 eb 3e bb 37 df 52 8a a4 f0 96 21 af 5d f0 cb c4
Cert Hash(sha256): 92048e3aeb6fc644e930b4c9e3a1d447e52c346091b826a220717bc31e309993
Signature Hash: 05c91314bbe66b58e6f870f57733dfdb456eb5e0
I do not trust the issuer of this certificate (NewMedia-NET GmbH), but that is not what the message in the certificate properties mean. Neither was this a problem with validity since the certificate is valid for almost 10 years at the time of this writing. Even adding this certificate to the Trusted Root Certificate store will not resolve this problem. The reason is to be found in the Public Key Length field. In this certificate the public key is only 512 bytes. In August of 2012 Microsoft released an update that will block any certificates with RSA keys less than 1024 bits in length. This was done to make sure that a private key cannot be discovered using brute force methods and thus exposing private information. After the update the CryptoAPI, which builds a certificate trust chain and validates that chain by using time validity, certificate revocation, and certificate policies (such as intended purposes), implements an additional check to make sure that no certificate in the chain has an RSA key length of less than 1024 bits. Any such certificates will not be trusted.
Actually the error displayed by Internet Explorer; “The security certificate presented by this web site is not secure” makes more sense than the messages in the certificate properties (“This certificate has an invalid digital signature”). Because that is actually what is happening; the certificate is not good enough to protect whatever data your are transmitting between the client and the server. So how come, according to the CryptoAPI extension, the digital signature is not valid?
In public key cryptography the private key is generated from the public keys, or rather, the very large prime numbers selected to be the public key. That means that if the public key is weak, i.e. less than 512 bytes, the resulting private key would be as well. Since it is the issuing authority’s private key that is used to sign the issued certificate the signature itself would also be weak. And that is why the CryptoAPI displays the message “This certificate has an invalid digital signature”. What it should have displayed is something along the lines of “this certificates was signed with a weak private key etc.”.
If you are desperate to use certificates with key lengths less than 1024 bits you can override the restrictions imposed by the Microsoft update. How to do that is documented in the KB article accompanying the update. Here is the command I ran to test that I was on the right track and force IE to let me use the certificate:
certutil -setreg chainminRSAPubKeyBitLength 512
After running this IE have me this for the certificate:
As you can see the signature error is now gone (overridden) and we are back to a regular “this cert is not trusted” message.
But since I did not want to use any weak certs I removed the override and instead replace the certificate on the router with a proper V3 2048 bits certificate. This is the command to revert to the new behavior of blocking keys with less than 1024 bits:
certutil -delreg chainMinRsaPubKeyBitLength
More information:
