CertWatch 1.0 has been submitted to Addons.Mozilla.Org (AMO) and it will take a few days before it gets reviewed and released to CertWatch AMO page. Currently, AMO has the previous version of Certificate Watch, CertWatch 0.8.
For now, here are a couple of screenshots of CertWatch 1.0.
Certwatch 1.0 - Running for the first time
Firefox 3.6.8 comes with 149 root certificates and four intermediate certificates. While you browse and visit secure sites, there are intermediate certificates that are added to Firefox (in a file in your profile). Here I did some browser before installing the add-on, hence it shows five intermediate certificates.
CertWatch 1.0 - Visiting a secure website and certificates
Here we visited https://launchpad.net/. The certificate chain is composed of a website certificate, a single intermediate certificate and a root certificate.
On the tabs, in the parenthesis, the number denotes how many times those certificates have been used when we visit secure websites. Since we just started, they show “1”.
The stars next to the number show whether our preferences specify that we should show the specific certificate to the user. The default for CertWatch is to show each certificate for the first time it is used only. Therefore, all three certificates have a star.
Once you install, select to restart your browser. Note that when you restart your browser, CertWatch performs an analysis of your Firefox’s root certificates and adds them to its own copy, in the file CertWatchDB2.sqlite, in your profile folder. This analysis may take up to 30 seconds (if your computer is slow), therefore be patient.
First use
CertWatch 0.8 - First time use
Once you have installed CertWatch 0.8 and you restart Firefox, you are presented with a dialog similar to the one above. It shows the number of root certificates (includes what we call “intermediate” certificates as well) that have been read from Firefox and saved in CertWatch’s database. In CertWatch we distinguish between root and intermediate certificates. Click OK and you are read to surf.
Preferences
The CertWatch preferences are accessible from Tools » CertWatch Preferences.
CertWatch 0.8 Preferences dialog
When you visit a secure (i.e. https://) website, Firefox verifies whether the website certificate (secure websites come with “certificates”) is vouched by some authority, a Certification Authority (CA). These Certification Authorities are the 177 root certificates we saw earlier. There is a link between a website certificate and a corresponding root certificate in Firefox. In addition, between the website and root certificates there might be more certificates, the intermediate certificates. All these together make a chain.
So, when you visit a secure website, Firefox finds all the elements of the certification chain and verifies that a website is secure.
Once of the principle tasks of CertWatch is to keep track how many times a certificate has been accessed. When you repeatedly visit secure websites, the same certificates are used. So, with these preferences, CertWatch asks you how often to get notifications when certificates are accessed. The default is, when any new certificate is accessed, to show some notification.
In CertWatch 0.8 you can select up to how many times a new certificate (either website or root/intermediate) should be shown, when you visit a secure website.
CertWatch 0.8 - Website certificate
This is a website certificate; every secure website has one of those. Issued To are the details of the website according to the certificate. Issued By are the details of the certification authority that vouches for the website certificate. From these details we do not know yet whether this Thawte certificate is a root certificate or whether it’s an intermediate certificate with some other root certificate on top.
Validity shows when the certificate was issued and when it expires. I hope you like the human-readable text next to the dates. Finally, the SHA-1 fingerprint of the certificate is shown. We keep track of the fingerprints in the CertWatch database; it helps to identify if something strange changed in the chain.
Certwatch 0.8 - Intermediate certificate
These are the details of the Thawte certificate. It is issued by a Verisign certificate so we know that the Thawte certificate is an intermediate certificate. We will see below whether the Verisign certificate is the root certificate or just an intermediate certificate.
Why does Verisign vouch for a Thawte certificate? Aren’t they different companies? Thawte was a South African company by Mark Shuttleworth (Ubuntu fame, cosmonaut) who sold his company in 1999 to Verisign. Now Thawte is part of Verisign.
You can notice the validity, compared to the validity of the website certificate. The more we move towards the root certificate, the validities become wider (compare two years to ten years for website and intermediate respectively).
Certwatch 0.8 - Root certificate
This is the root certificate. The Issued To and Issued By details are the same. In CertWatch 1.0 this detail will be more visual than having to compare strings.
Although this certificate is for Google (I am insinuating quality), it is amazing how old the certificate is. It hails from 1996. The validity span is over 30 years. A piece of information that we do not show yet in CertWatch is the key size; this Verisign certificate from 1996 has a key size of 1024 bits. If you read the security news, you may have noticed complaints about this root certificate. It gets a bit worse; both this Verisign and the Thawte certificates have 1024-bit keys.
Are these two 1024-bit keys compromised? We can only speculate at this time. It will helps us figure out the answer if we can find out, how much harder it is to perform calculations between 1024-bit and 2048-bit RSA keys, and multiply that with the millions that connect to Google and GMail every day. If the computation requirements are not very different between the two, then there is no reason to keep 1024-bit keys.
If you visit https://billing.microsoft.com/ with Firefox, you will be confronted with an error message that the certificate is invalid. The reason is that the website is vouched by a new root certificate by Microsoft, that Microsoft appears not to have done the proper procedure to contact the Mozilla Foundation and add the root certificate.
Using CertWatch we managed to extract the certificate file (other methods also exist).
Here are the details of this billing.microsoft.com root certificate:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
6a:80:24:5c:00:08:00:01:9c:18
Signature Algorithm: sha1WithRSAEncryption
Issuer: DC=com, DC=microsoft, DC=corp, DC=redmond,
CN=Microsoft Secure Server Authority
Validity
Not Before: Jul 9 03:16:55 2010 GMT
Not After : Jul 9 03:16:55 2011 GMT
Subject: C=US, ST=Washington, L=Redmond, O=Microsoft,
OU=Windows Live Operations, CN=billing.microsoft.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:ab:d7:34:a7:58:eb:89:b8:a0:3c:5a:d4:fb:d5:
49:1e:6c:51:79:d0:dc:49:03:3d:11:e8:79:2c:e2:
c8:24:e4:d0:a8:45:57:c1:fd:b9:9e:ed:c0:c5:e6:
94:ae:96:45:db:ce:14:29:63:34:55:f4:e9:3a:d1:
4e:be:45:06:db:ef:f0:95:7d:dd:63:21:81:6e:d6:
1f:8a:7d:59:80:83:df:59:a8:a6:6e:b3:82:ea:af:
80:43:79:45:45:af:fb:5e:66:83:4d:b2:23:13:ff:
bc:67:5d:a5:7b:03:81:e5:24:7f:31:2d:5b:1d:98:
ed:c5:53:73:17:2e:7e:c4:cd
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage:
Digital Signature, Key Encipherment, Data Encipherment
S/MIME Capabilities:
......0...+....0050...*.H..
..*.H..
X509v3 Extended Key Usage:
TLS Web Client Authentication, TLS Web Server Authentication
X509v3 Subject Key Identifier:
69:47:71:B7:BA:81:B5:35:50:69:AC:DB:46:18:F2:5F:82:83:9B:D5
X509v3 Authority Key Identifier:
keyid:08:42:E3:DB:4E:11:66:F3:B5:08:C5:40:DB:55:7C:33:46:11:83:38
X509v3 CRL Distribution Points:
URI:http://mscrl.microsoft.com/pki/mscorp/crl/Microsoft%20Secure%20Server%20Authority(8).crl
URI:http://crl.microsoft.com/pki/mscorp/crl/Microsoft%20Secure%20Server%20Authority(8).crl
URI:http://corppki/crl/Microsoft%20Secure%20Server%20Authority(8).crl
Authority Information Access:
CA Issuers - URI:http://www.microsoft.com/pki/mscorp/Microsoft%20Secure%20Server%20Authority(8).crt
CA Issuers - URI:http://corppki/aia/Microsoft%20Secure%20Server%20Authority(8).crt
1.3.6.1.4.1.311.21.7:
00.(+.....7.....M..........}...t.O.........c..d...
1.3.6.1.4.1.311.21.10:
0.0
..+.......0
..+.......
Signature Algorithm: sha1WithRSAEncryption
77:62:04:97:b2:38:c5:90:1e:9f:8d:03:16:bd:79:c9:c9:54:
cb:f3:94:b4:7a:fa:18:de:95:54:20:1f:3a:bd:72:c2:d9:46:
d5:af:b9:72:5a:a2:52:5f:42:89:16:b8:60:f7:00:74:19:e8:
de:23:64:0c:a2:6e:64:7c:22:aa:58:a0:25:59:24:b5:30:54:
2f:a3:be:db:b7:6d:ce:02:37:37:d8:c0:11:c5:62:d8:81:84:
cd:c3:e3:15:36:33:56:97:7f:68:d9:ab:d4:ac:5a:9b:f5:99:
be:52:4d:f1:c4:32:40:0d:ed:27:59:36:75:3c:a5:27:6e:66:
43:b8:82:56:74:eb:ab:62:5f:5d:96:b8:ba:0d:59:f7:1f:f4:
8d:e1:ff:88:0d:5d:76:10:3e:90:46:85:5e:f9:a7:13:b8:11:
e8:39:79:49:c6:5a:04:55:c9:bf:fb:b9:6a:ea:2a:2b:ab:0a:
97:3b:86:78:5c:2e:28:39:19:c6:29:66:32:a8:60:d8:55:2b:
71:4c:ff:e1:69:7c:40:a0:6c:86:49:fe:f8:0d:f4:8c:2c:03:
e2:45:16:fd:0a:72:c1:90:4e:8c:ff:b0:e8:9b:1f:0f:51:f0:
3e:40:a2:4a:10:70:48:6e:a7:08:8f:59:bc:61:96:1e:85:11:
ea:db:63:64
If you can factorise this number, then you have broken the certificate.
Apparently this certificate is accepted by recent versions of Internet Explorer and Chrome. With this information at hand, I do not see how these browsers accept the root certificate which is also a website certificate (an oddity). Currently, the only explanation at hand would be that those browsers either have a copy of this root certificate or they use another (unknown to me) cryptographic mechanism to verify the certificate.
