Certificate Error

Access Local Machine certificates without Admin rights

2011-08-14T21:16:00.000+02:00

Digital certificates in windows, either the end entitty certificates, called Personal Certificates, the subCAs or the Root CAs, are stored in the so called Certificate Stores. There are different types of Certificate Stores but the more relevant ones are:

• Personal CA Store: Certificates, either end entities, subCAs or Root CAs, that apply to the current user

• Local Machine CA Store: Certificates, either end entities, subCAs or Root CAs, that apply to the system account. These apply to the user too. This means that a certificate issued by a Root CA available in the Local Machine CA Store but missing in the Personal CA Store would be treated as a valid.

In order to have access to the digital certificates used by Windows and integrated applications you need to follow these steps: (Have in mind that Firefox uses its own digital certificate stores).

From the command line open an MMC:

In the MMC add the Certificate snap-in

If you have local machine admin rights you have the right to choose the CA Store you want to open, if not it will automatically open the Personal CA Store

The naming can be a bit confusing but you should concentrate in the following folders:

• Personal: These are the end entity certificates assigned to the account (User or System)
• Trusted Root Certification Authorities: The Root CAs
• Intermediate Certificate Authorities: The subCAs

From the Certificate console, you are able to browse, add, delete all different types of certificates. If you need information of the other folders you can check the Microsoft article https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/sag_cmuncertstor.mspx .

As said, if the user does not have admin rights he won´t be allowed to choose the “Computer account” where the certificates that apply to the System account are stored. Something that creates a bit of confusion is the fact that the Root CAs and subCAs from that store apply to the current user. Unfortunately these can only be examined by the end user in case his account has local admin machine rights. Although it’s understandable that a restricted user should not be available to apply changes that will affect all users, it makes no sense that it is not allowed to list the complete list of Root CAs available in the System account and that will be trusted in any SSL connection he establishes.

The good news is that the restrictions to access the Local Machine CA Store are rather weak and I just found a quick workaround for this.

From a computer where you have admin rights perform the steps above and repeat them adding the Computer Account. You should have a console with entries to the user and system accounts:

Go to "File -> Save as" and save the console (with extension msc) in a known directory. Transfer the file using a USB disk or by email to the target computer and you will be able to access the “restricted” Local Machine Store even if the logged user does not have local admin rights.

This is a simple hack but very useful when troubleshooting certificate related problems when users have restricted accounts. I have tested in a Windows 7, if you test it in other platforms let me know the results.

I just hope that the rest of the Windows 7 access control mechanisms are more robust than this!

Android default (weak) signing configuration for the developer certificates

2011-05-04T19:33:00.000+02:00

Some months ago I created a couple of Android applications. As every Android developer knows, in order to deploy applications on Android devices, these need to be signed. In other platforms like IOS, Symbian, Java or Windows Mobile, the signing process is a method used to prove the source of an application. Once an application is signed by a known certification authority, the platform will grant different execution permissions. Android used code signing slightly different. The developer creates its own self signed certificate and uses this to sign any application he releases. This allows the platforms to recognize updates and also allow secure inter application communication. The reason is simple, if there was no way to relate an application to its owner it would be trivial to impersonate him or her and deliver fake applications updates.

Without wanting to dig into the controversy between open and closed models, IOS vs Android, the part that caught my attention was that the developer would create a self signed certificate on his own and that that the only requirement is that the certificate must be valid until 2034. Today we all know that MD5 is proven to be weak and that key sizes should be at least 2048b, especially if we need to use it for a few years. On the other hand the default Android tools I used to create the certificate suggested to use a 1024b key and MD5 which is not a good idea, especially if that would be my identification until 2033!!

With that in mind I was curious to see how the digital certificates used to sign Android applications would look like. I analyzed nearly 4.000 applications, extracted the certificates and put together some statistics. For this I used unique certificates, which means that if two applications (in most cases these were updates) were signed with the same certificate I only took into consideration one occurrence.

First lets have a look at the algorithms being used:

As you can see the most used algorithm is RSA with SHA1 as a hashing algorithm but nearly one every 5 uses MD5 as a hashing algorithm.

The strongest hashing algorithm found was SHA256 (1 occurrence, removed from the char) and the weakest MD5. It´s remarkable to see a 6% of DSA which is a n algorithm rarely used for X509 certificates, although perfectly valid.

Regarding key sizes for RSA we have the following distribution:

The most used key size is 1024b. Although I removed them from the pie charts, the weakest key size was 1023b (9 occurrences) and the strongest 8192b (1 occurrence).

Developers, and some sysadmins too, tend to see digital certificates, and everything else around it, private keys, Root CAs, CRLs, etc as an annoyance and in the best cases as another “configuration” file. Having in mind that Android forces you to use selfsigned certificates valid until 2033 it would be good to invest some time explaining developers the importance of the certificate/key and even more important enforce the use by default of stronger algorithms. Seeing the capabilities of the platform I don´t understand why Google did not enforce a minimum key length of 2048b and SHA1 or even better SHA256, instead of using default weaker settings especially when forcing developers to generate certificates valid for so long.

How to validate the Subject Key Identifier (SKI) from a X509 certificate

2011-02-17T20:18:00.000+01:00

Some days ago I received an odd complain that some of the Root CAs we use had the wrong Subject Key Identifier (SKI). I knew that the claim was false but I also knew that I'll have to prove it. The guy did dig on our own specifications and calculated the SKI as we required, the hash of the certificate public key but unfortunately the identifiers did not match.

In order to reproduce the problem I extracted the public key of the Root CA, converted to DER, hashed it with SHA1 and verified that indeed the hash did not match. Let’s do a demonstration of what I did with a public available Root CA:

openssl x509 -in GSRootCA-2014.cer -inform DER -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            02:00:00:00:00:00:d6:78:b7:94:05
        Signature Algorithm: md5WithRSAEncryption
        Issuer: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA
        Validity
            Not Before: Sep  1 12:00:00 1998 GMT
            Not After : Jan 28 12:00:00 2014 GMT
        Subject: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:da:0e:e6:99:8d:ce:a3:e3:4f:8a:7e:fb:f1:8b:
                    83:25:6b:ea:48:1f:f1:2a:b0:b9:95:11:04:bd:f0:
                    63:d1:e2:67:66:cf:1c:dd:cf:1b:48:2b:ee:8d:89:
                    8e:9a:af:29:80:65:ab:e9:c7:2d:12:cb:ab:1c:4c:
                    70:07:a1:3d:0a:30:cd:15:8d:4f:f8:dd:d4:8c:50:
                    15:1c:ef:50:ee:c4:2e:f7:fc:e9:52:f2:91:7d:e0:
                    6d:d5:35:30:8e:5e:43:73:f2:41:e9:d5:6a:e3:b2:
                    89:3a:56:39:38:6f:06:3c:88:69:5b:2a:4d:c5:a7:
                    54:b8:6c:89:cc:9b:f9:3c:ca:e5:fd:89:f5:12:3c:
                    92:78:96:d6:dc:74:6e:93:44:61:d1:8d:c7:46:b2:
                    75:0e:86:e8:19:8a:d5:6d:6c:d5:78:16:95:a2:e9:
                    c8:0a:38:eb:f2:24:13:4f:73:54:93:13:85:3a:1b:
                    bc:1e:34:b5:8b:05:8c:b9:77:8b:b1:db:1f:20:91:
                    ab:09:53:6e:90:ce:7b:37:74:b9:70:47:91:22:51:
                    63:16:79:ae:b1:ae:41:26:08:c8:19:2b:d1:46:aa:
                    48:d6:64:2a:d7:83:34:ff:2c:2a:c1:6c:19:43:4a:
                    07:85:e7:d3:7c:f6:21:68:ef:ea:f2:52:9f:7f:93:
                    90:cf
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Subject Key Identifier:
                60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B
            X509v3 Basic Constraints: critical
                CA:TRUE
    Signature Algorithm: md5WithRSAEncryption
        ae:aa:9f:fc:b7:d2:cb:1f:5f:39:29:28:18:9e:34:c9:6c:4f:
        6f:1a:f0:64:a2:70:4a:4f:13:86:9b:60:28:9e:e8:81:49:98:
        7d:0a:bb:e5:b0:9d:3d:36:db:8f:05:51:ff:09:31:2a:1f:dd:
        89:77:9e:0f:2e:6c:95:04:ed:86:cb:b4:00:3f:84:02:4d:80:
        6a:2a:2d:78:0b:ae:6f:2b:a2:83:44:83:1f:cd:50:82:4c:24:
        af:bd:f7:a5:b4:c8:5a:0f:f4:e7:47:5e:49:8e:37:96:fe:9a:
        88:05:3a:d9:c0:db:29:87:e6:19:96:47:a7:3a:a6:8c:8b:3c:
        77:fe:46:63:a7:53:da:21:d1:ac:7e:49:a2:4b:e6:c3:67:59:
        2f:b3:8a:0e:bb:2c:bd:a9:aa:42:7c:35:c1:d8:7f:d5:a7:31:
        3a:4e:63:43:39:af:08:b0:61:34:8c:d3:98:a9:43:34:f6:0f:
        87:29:3b:9d:c2:56:58:98:77:c3:f7:1b:ac:f6:9d:f8:3e:aa:
        a7:54:45:f0:f5:f9:d5:31:65:fe:6b:58:9c:71:b3:1e:d7:52:
        ea:32:17:fc:40:60:1d:c9:79:24:b2:f6:6c:fd:a8:66:0e:82:
        dd:98:cb:da:c2:44:4f:2e:a0:7b:f2:f7:6b:2c:76:11:84:46:
        8a:78:a3:e3

Now let's calculate the SHA1 of the public key:

openssl x509 -in GSRootCA-2014.cer -inform DER -pubkey -noout|
  openssl rsa -pubin -outform DER| 
  openssl dgst -c -sha1
87:db:d4:5f:b0:92:8d:4e:1d:f8:15:67:e7:f2:ab:af:d6:2b:67:75

As reported, both hashes did not match!

At this point I was a bit confused and decided to read some documentation before moving forward. After some reading I found the answer in the 4.2.1.2 section of the the RFC3280 “Internet X.509 Public Key Infrastructure - Certificate and Certificate Revocation List (CRL) Profile ” (http://www.ietf.org/rfc/rfc3280.txt)

4.2.1.2  Subject Key Identifier

   The subject key identifier extension provides a means of identifying
   certificates that contain a particular public key.

   To facilitate certification path construction, this extension MUST
   appear in all conforming CA certificates, that is, all certificates
   including the basic constraints extension (section 4.2.1.10) where
   the value of cA is TRUE.  The value of the subject key identifier
   MUST be the value placed in the key identifier field of the Authority
   Key Identifier extension (section 4.2.1.1) of certificates issued by
   the subject of this certificate.

   For CA certificates, subject key identifiers SHOULD be derived from
   the public key or a method that generates unique values.  Two common
   methods for generating key identifiers from the public key are:

      (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
      value of the BIT STRING subjectPublicKey (excluding the tag,
      length, and number of unused bits).

      (2) The keyIdentifier is composed of a four bit type field with
      the value 0100 followed by the least significant 60 bits of the
      SHA-1 hash of the value of the BIT STRING subjectPublicKey
      (excluding the tag, length, and number of unused bit string bits).

In our case we use method 1) for the SKI but in my calculations I was taking into consideration the whole public key, including tag, length, etc, while I should have used the key bits only.
With the following command I was able to locate the “BIT STRING” with the naked key:

openssl x509 -noout -in GSRootCA-2014.cer -inform DER -pubkey| 
 openssl asn1parse
    0:d=0  hl=4 l= 290 cons: SEQUENCE
    4:d=1  hl=2 l=  13 cons: SEQUENCE
    6:d=2  hl=2 l=   9 prim: OBJECT            :rsaEncryption
   17:d=2  hl=2 l=   0 prim: NULL
   19:d=1  hl=4 l= 271 prim: BIT STRING

And I only need to extract it and put it on a file in DER format:

openssl x509 -noout -in GSRootCA-2014.cer -inform DER -pubkey|
 openssl asn1parse  -strparse 19 -out pub.der
    0:d=0  hl=4 l= 266 cons: SEQUENCE
    4:d=1  hl=4 l= 257 prim: INTEGER           :DA0EE6998DCEA3E34F8A7EFBF18B83256BEA481FF12AB0B995110...
DDCF1B482BEE8D898E9AAF298065ABE9C72D12CBAB1C4C7007A13D0A30CD158D4FF8DDD4...
73F241E9D56AE3B2893A5639386F063C88695B2A4DC5A754B86C89CC9BF93CCAE5FD89F5...
6D6CD5781695A2E9C80A38EBF224134F73549313853A1BBC1E34B58B058CB9778BB1DB1F...
2608C8192BD146AA48D6642AD78334FF2C2AC16C19434A0785E7D37CF62168EFEAF2529F...
  265:d=1  hl=2 l=   3 prim: INTEGER           :010001

The remaining part was to calculate the SHA1 hash which was the same as the SKI:

openssl dgst -c -sha1 pub.der
SHA1(pub.der)= 60:7b:66:1a:45:0d:97:ca:89:50:2f:7d:04:cd:34:a8:ff:fc:fd:4b

The same method was used to verify the SKI of a Root CA using SHA256 as a hashing algorithm.

Mobile operators header enrichment assessment 6/6: Summary

2010-09-27T22:26:00.000+02:00

During the last weeks I have been posting the results of header enrichment assessment I've done in several mobile operators. Let's do a quick check and summarize the results.

1) All operators in the same country have similar configurations. I was surprised to see how mobile operators appear to mimic other operators in the same territory.
2) Most operators have transparent proxies operating on the "Internet" connections.
3) As seen, some operators allow third parties to track users without the user consent and without allowing them to change or hide these traces. They add an HTTP header with an ID that uniquely identify the user. Some operators will change that ID every 24h like Orange Spain or Orange UK but some will keep the same ID forever. The worst ranking operators from the user privacy point of view are TIM Italy, Vodafone Italy, Telefonica Spain and Vodafone Spain.
4) Several ones are disclosing unnecessary information that reveals data that could be misused. From the information disclosure point of view the worst operator is Orange UK followed by SFR in France.
5) The winner of the header overhead would be Orange Spain which doubles all the Accept Headers,
6) and the winners of the header manipulation are TIM in Italy and Eplus in Germany.
I hope you enjoyed this series of posts. Feel free to leave your comment and let me know if some of the results change.

Mobile operators header enrichment assessment: Part 5/6 - UK

2010-09-22T21:35:00.000+02:00

And today, the last group of mobile operators assessed. We had a look at the mobile operators in the UK: TMobile, Vodafone, Orange, O2/Telefonica and 3, and these are the results:

=== TMobile UK through WAPGW/Proxy ===
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1
Cache-Control: max-age=43200
Connection: keep-alive

=== TMobile UK direct INTERNET connection ===
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1-dir
Cache-Control: max-age=43200
Connection: keep-alive

We can see that TMobile UK is adding just a couple of proxy related HTTP headers and also that all the request in the Internet connections go trough a transparent proxy.

=== Vodafone UK through WAPGW/Proxy ===
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Encoding: deflate, gzip, identity
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1
Via: HTTP/1.1 begwsl12 (XMS 724Solutions HTG XFW_004_M00_B133 20100521.012244)
Connection: close

=== Vodafone UK direct INTERNET connection ===
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Encoding:
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1-dir
Connection: TE, close

In Vodafone UK we have a similar behavior as in TMobile, all connections go through a proxy, even the Internet ones. In the WAP connection they add a "Via" HTTP header. Although that is a standard proxy header, seeing that it is not added by most operators I would not add it here either.

=== O2/Telefonica through WAPGW/Proxy ===
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1
X-Forwarded-For: 10.86.161.95
Cache-Control: max-age=43200
Connection: keep-alive

=== O2/Telefonica UK direct INTERNET connection ===
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1-dir
Cache-Control: max-age=43200
Connection: keep-alive

In O2/Telefonica we see a similar behavior as in Vodafone UK or TMobile UK. Everthing goes trough a proxy but in here we see that the WAP connection adds the X-Forwarded-For, which, although it is a standard, nowadays adds little or no value.

=== 3 UK direct INTERNET connection ===
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1-dir
Cache-Control: max-stale=0
Connection: Keep-Alive
X-BlueCoat-Via: 03F39CF1D18B00C3

3 in UK, as 3 in Italy, does not have a WAP connection with a fixed proxy. Nevertheless we see they use a transparent proxy too as they are adding some extra HTTP headers.

=== Orange UK through WAPGW/Proxy ===
X-ICAP-Version: 1.0
Connection: keep-alive
Content-Length: 0
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1
X-Nokia-RemoteSocket: 10.37.7.162:11961
X-Nokia-LocalSocket: 193.35.132.107:8080
X-Nokia-Gateway-Id: NBG/1.0.91/91
X-Nokia-BEARER: GPRS
X-Nokia-CONNECTION_MODE: TCP
X-Orange-ID: 2/oj/g2sxXXXXXXXXXXXX==
X-Forwarded-For: 10.37.7.162, 193.35.132.106
Via: 1.1, 1.1 pg-proxy1 (NetCache NetApp/6.0.6P1)

=== Orange UK direct INTERNET connection ===
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1-dir
X-Nokia-BEARER: GPRS
X-Operator-Domain: orange.co.uk
X-Orange-Roaming: NO
X-Orange-ID: OR4B9UD7xXXXXXXXXXXXXX==
Via: 1.1 pg_squid4_3 (squid)
X-Forwarded-For: 172.24.36.9
Cache-Control: max-age=259200
Connection: keep-alive

In Orange UK we see one of the examples of HTTP header overhead. We can see all the useless Nokia headers and this time I´d like to highlight the following ones:

X-Nokia-RemoteSocket: 10.37.7.162:11961
X-Nokia-LocalSocket: 193.35.132.107:8080

The bigmouthed Nokia GW is telling us that the mobile device has the IP 10.37.7.162 and a socket connecting from port 11961 to the GW IP 193.35.132.107 and port 8080. I can think of a couple of tests that could be done with this information...

Another piece of useful information is that Orange is using a Nokia GW for the WAP connection and a Squid proxy as a transparent proxy.
Regarding the header

X-Orange-ID: OR4B9UD7xXXXXXXXXXXXXX==

this is a unique ID that is being updated every 24h. Needed?.... not really. Harmful? not too much.

Except Orange, the Mobile Operators in the UK seam to do a good job, not allowing third parties to track their customers and having light proxys. What they all have is a transparent proxy on the Internet connection which seems to be quite common in most operators. Next post will be a summary of the assessed operators.

Mobile operators header enrichment assessment: Part 4/6 - Spain

2010-09-21T20:06:00.000+02:00

This time we´ll go for the main mobile operators in Spain: Orange, Vodafone and Telefonica/Movistar.
See the previous posts if you need more information on the procedure.

=== Orange Spain through WAP GW/Proxy ===TE: deflate,gzip;q=0.3
Accept: text/html, text/vnd.wap.wml, application/vnd.wap.html+xml, application/xhtml+xml, application/vnd.wap.xhtml+xml, text/x-wap.wml, text/x-hdml, text/vnd.sun.j2me.app-descriptor, application/java-archive, application/octet-stream, image/png, image/gif, image/jpg, image/jpeg, */*, text/x-vcard, text/x-vcalendar, image/vnd.wap.wbmp
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1
Content-length: 0
Via: WTP/1.1 nwg3 (Nokia WAP Gateway 4.1/CD21/4.1.116)
X-Nokia-CONNECTION_MODE: TCP
X-Nokia-BEARER: CSD
X-Nokia-GATEWAY_ID: NWG/4.1/Build116
x-nokia.wia.accept.original: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,image/png,image/gif,image/jpg,image/jpeg,*/*,text/x-vCard,text/x-vCalendar,image/vnd.wap.wbmp
Connection: close
x-up-calling-line-id: RKWsZys5JJXXXXXXXXXXXX==

=== Orange Spain direct INTERNET connection===
TE: deflate,gzip;q=0.3
Connection: TE, close
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1-dir

As you can see the GW in Orange Spain is adding a lot of overhead. For what we have seen before it seems to be a standard procedure on Nokia GWs but in my eyes this configuration is the worst we have seen so far. The GW is duplicating the "Accept" header which is the header with the biggest amount of information. For instance a random Nokia Series 60 device has the following "Accept" header:

application/vnd.ces-quicksheet, audio/wav, audio/x-wav, audio/basic, audio/x-au, audio/au, audio/x-basic, video/mp4, video/mpeg4, video/3gpp, application/vnd.rn-realmedia, audio/amr-wb, audio/amr, audio/mp3, application/sdp, audio/sp-midi, audio/x-beatnik-rmf, audio/midi, audio/aac, audio/mpeg, audio/3gpp, audio/mp4, application/java-archive, text/vnd.sun.j2me.app-descriptor, text/html, application/vnd.wap.xhtml+xml, application/xhtml+xml, application/vnd.wap.wmlc, text/vnd.wap.wml, application/vnd.wap.wbxml1, application/vnd.wap.wmlscriptc, multipart/mixed, application/x-javascript, text/ecmascript, application/x-nokiaGameData, application/vnd.ces-quickword, application/vnd.ces-quickpoint, text/x-co-desc, application/vnd.symbian.install, audio/x-pn-realaudio-plugin, audio/x-pn-realaudio, audio/mpegurl, audio/x-mpegurl, application/vnd.oma.dd+xml, application/x-wallet-appl.user-data-provision, application/vnd.met.ticket, application/vnd.nokia.ringing-tone, text/vnd.symbian.wml.dtd, application/vnd.wap.wbxml, application/java, video/3gp, audio/rmf, audio/x-rmf, audio/x-midi, application/x-java-archive, application/vnd.oma.drm.message, application/x-x509-ca-cert, text/plain, text/X-vCard, text/calendar, text/x-vCalendar, text/css, image/*

If that is already insane, imagine once the GW has doubled it...

The good news for Orange Spain customers is that they are not sending the customer phone number in their headers any more (+info in Orange Spain disclosing user phone number). They now show the following HTTP header:
x-up-calling-line-id: RKWsZys5JJXXXXXXXXXXXX==

and I´ve verified that is changing every 24hours. Well done! Also for Orange direct internet connections there seems to be no transparent proxy or if there is, the headers are not modified.

==== Vodafone Spain ===
accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
accept-charset: iso-8859-1,utf-8
accept-language: en-us,en;q=0.5
user-agent: HeaderValidator/1.1
x-up-subno: vTCMMfb8WXXXXXXXXXXXXX==
X-Forwarded-For: 213.30.40.121
Cache-Control: max-stale=0
Connection: Keep-Alive
X-BlueCoat-Via: 98586C1EE63C311A

InVodafone Spain we have another example of GW rewriting all headers to lowercase. On the other hand there is not much overhead but there is another case of unlawful user tracking. The header
x-up-subno: vTCMMfb8WXXXXXXXXXXXXX==
is fixed per user and the user is not able to remove or update it.

=== Telefonica Spain through WAP GW/Proxy ===
TM_user-id: 0342530XXXXXXXXXXXX
x-up-subno: 0342530XXXXXXXXXXXX
Connection: close
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*,*/*
Accept-Charset: iso-8859-1,utf-8,*
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1 UP.Link/6.3.1.15.0
x-up-forwarded-for: 10.167.43.248
x-up-subscriber-coi: coiwap
Via: 1.1 bgui-lwp01_coi1.openwave.com:8080

=== Telefonica Spain direct INTERNET connection===
TE: deflate,gzip;q=0.3
Connection: TE, close
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1-dir

Telefonica Spain is also tracking its WAP users with a fixed number, without allowing them to change the id, and also without notifying them. The "not that bad news" is that they are not using it on the Internet connection. Which means this is affecting all Symbian users but not the iPhones or Androids. There is also some unnecessary information disclosure though. Do we need to know they have an Openwave GW Version 6.3.1.15.0? or the Subscriber "coi" whatever that is? I don´t think so.

In summary Spanish Operators like to track users and users have no way to modify this.
Next time we´ll take a boat and see how UK is doing.

Mobile operators header enrichment assessment: Part 3/6 - Germany

2010-09-17T23:13:00.000+02:00

This time we will have a look at the mobile operators in Germany. The good news is that there are no major issues, the bad is that it made the assessment less interesting.

=== Vodafone Germany WAPGW/Proxy ===
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1
Cache-Control: max-age=43200
Connection: keep-alive

=== Vodafone Germany INTERNET connection ===
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1-dir
Cache-Control: max-age=43200
Connection: keep-alive

The only finding in Vodafone Germany is that they use a transparent proxy for all Internet connections which probalby is the same as the WAP GW. They seam to have a caching Proxy (Cache-Control: max-age=43200) but besides that the treatment of the HTTP headers looks good.

=== O2/Telefonica Germany WAPGW/Proxy ===
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
Connection: TE, close
User-Agent: HeaderValidator/1.1
X-WAPIPADDR: 10.62.141.232

=== O2/Telefonica Germany INTERNET connection ===
TE: deflate,gzip;q=0.3
Connection: TE, close
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1-dir

O2 Germany does not seams to have a transparent proxy or if it has, it's not the same as the WAP one. The WAP GW slightly reorders the HTTP headers and adds one extra header. Like in the case of Vodafone Germany, no issues found.

=== TMobile Germany WAPGW/Proxy ===
TE: deflate,gzip;q=0.3
Connection: TE, close
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1-dir
X-Forwarded-For: 10.197.17.29
Cache-Control: max-age=4300

We can see that the TMobile Germany WAP GW is adding a couple of extra headers. Once more I would not at the X-Forwarded-For, but is not a big deal either.

=== Eplus WAPGW/Proxy ===
accept-language: en-us, en;q=0.5
user-agent: HeaderValidator/1.1
accept: text/html,*/*;q=0.001,image/jpeg,image/jpg,image/gif,image/png,application/octet-stream,application/java-archive,text/vnd.sun.j2me.app-descriptor,text/x-hdml,text/x-wap.wml,application/vnd.wap.xhtml+xml,application/xhtml+xml,application/vnd.wap.html+xml,text/vnd.wap.wml
accept-charset: iso-8859-1,utf-8,*;q=0.001
accept-encoding: *;q=0.001

=== Eplus WAPGW/Proxy ===
TE: deflate,gzip;q=0.3
Connection: TE, close
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1-dir

EPlus has the most intrusive GW in Germany. It rewrites all the HTTP headers to lower case and also adds the funny qualifier q=0,001 at the end of all content related ones. If you see the last post you´ll see that the behaviour is the same like in TIM Italy wich indicates they would most probably use the same GW. On the other hand the Internet connection seams untoched. I guess their GW is busy enough!

And that was all for Germany. Next would be Spain, which I promise it would more interesting.

Mobile operators header enrichment assessment: Part 2/6 - Italy

2010-09-15T22:03:00.000+02:00

This time we will have a look at how Mobile operators in Italy deal with the HTTP Header enrichment. If you have not read the previous post have a loot at Mobile operators header enrichment assessment: 1/6 - Introduction and France to understand the methodology used.

As in the case of France we use a script that sends the following HTTP headers and compares them with the ones that reach the server:

=== Original Headers ===
TE: deflate,gzip;q=0.3
Connection: TE, close
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1

This time we are assessing the following Italian network operators: TIM, Vodafone Italy and 3 Italy (Tre Italia).
I copy below the results and in red I highlight the unexpected changes, while in orange I mark the ones that were understandable for a proxied connection.

=== TIM through WAPGW/Proxy ===
pragma: no-cache
proxy-connection: Keep-Alive
accept-language: en-us, en;q=0.5
user-agent: HeaderValidator/1.1
x-up-subno: B01-XXXXXX-XXXX820394-mic08up01_waphsp.tim.it
accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*;q=0.001
accept-charset: iso-8859-1,utf-8,*;q=0.001
accept-encoding: *;q=0.001
Connection: close
X-Adit-Lpcnt: 1

It´s interesting to see that TIM GW is modifying all the HTTP headers. First of all it is changing the case to lower case and also "q=0,001" at the end of all Accept headers and changing the order. This means that when a new HTTP request comes in, the GW will read all the HTTP headers, parse them, change the case, reorder them and add the new sufix when relevant and create the new request. That seams to me a lot of work for a little or no gain.

Also notice the conflicting HTTP Headers:
proxy-connection: Keep-Alive
Connection: close

It´s fair for a proxy to add the "Keep-Alive" one but it should have removed the client "Connection: close". Also I don´t understand the purpose of adding q=0.001. If the client did not want to receive some kind of content, that header might confuse the servers and make them assume that, with a really low preference, the device will accept any content.

Last but not least, check the header:
x-up-subno: B01-XXXXXX-XXXX820394-mic08up01_waphsp.tim.it
which is a constant ID that is present in all the user connections, identifying all the HTTP Requests. Although there is no direct way to relate that ID to the real identity, there is also no way for the user to erase or reset it.

=== TIM direct INTERNET connection===
TE: deflate,gzip;q=0.3
Connection: TE, close
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1-dir

Looking at the headers it seems that TIM does not apply any transparent proxy on their Internet connection.

=== Vodafone Italy through WAP GW/Proxy ===
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Encoding: deflate, gzip, identity
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1
x-forwarded-for: 10.148.17.52
x-up-forwarded-for: 10.148.17.52
x-up-subno: g00gf1a3ffv4cfXXXXXXXXXXXXXXXXX
Via: HTTP/1.1 gmigmsp104 (XMS 724Solutions HTG XFW_002_M00_B247 20100413.142643)
Connection: keep-alive

Vodafone Italy is adding some unnecessary headers but not to the level of some of the French operators. Also, like TIM, Vodafone Italy is adding a fixed ID per user. An ID which will track the user always and that can`t be disabled.

=== 3 Italy direct INTERNET connection===
TE: deflate,gzip;q=0.3
Connection: TE, close
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1-dir

3 Italy is not adding any change on the HTTP headers. Note that 3 Italy does not use any GW and thus the only way to modify the headers would need to be using a transparent proxy.

And that is all for Italy, next time we´ll have a look at the German mobile operators.

Mobile operators header enrichment assement: 1/6 - Introduction and France

2010-09-12T20:23:00.000+02:00

During the last weeks I have been assessing how Mobile operators mangle HTTP connections and today I start a series of posts to present the results.

One of the main differences between mobile and fixed operators is that the first have been providing the so called Valued Added Services (VAS), while the second, in most cases, are just fat pipes. The main VAS enablers are the former Wireless Application Protocol Gateways (WAP GW).

Ten years ago, WAP GW had the important role to convert the efficient and compact WTP/WSP to the standard and broadly used TCP/HTTP. Nowadays, when all (relevant) devices support WAP2.0, WAP GW are not much different from any enterprise Proxy. The main difference is that in order to support the VAS, WAP GW enrich the HTTP headers. There are different flavors of header enrichment: on one hand the most common behavior includes adding a user ID, like the mobile phone (MSISDN) for dedicated internal services allowing the VAS to identify the user, and most probably charge him/her. On the other, some operators would modify the HTTP headers for different reasons. Also some others would add extra information like bearer type, Proxy ID, device real IP, etc.

The methodology for the tests is simple. I have several GPRS/UMTS modems with the SIM cards of the operators that I want to analyse. I created a script that would initiate a connection through a given modem from one of the mobile operators and access a server I own that replies with the HTTP headers that reached the server. As I know the headers I input and the ones that reach the server I can compare them and note the results.

When doing the connection to the operator I do it in two ways. First I would use the so called WAP connection and connect trough the WAP GW. In this case I´m simulating a standard mobile phone like most Nokia, Motorola, Samsung, Sony Ericcson.... In the second connection I would use the so called WEB or INTERNET connection, simulating an Android, iPhone or standard PC with a data card. Although most people think that in the second case the user is accessing the internet directly, without going through a proxy we will see that it is not the case. Since the advent of the Androids and iPhones, which do not support an operator proxy, mobile operators have deployed transparent proxies (aka intercepting proxies) on the "Internet" connection, forcing also these devices to go trough them.

Having said that, lets take a look at some real examples from the french mobile operators: Orange, SFR and Bouygues. First of all, these are the original headers of my script:

TE: deflate,gzip;q=0.3
Connection: TE, close
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1

whereas when using the direct connection the headers were the same but the User Agent was:
User-Agent: HeaderValidator/1.1-dir

Below I add the headers as received in the server for the different connections. In red I highlight the unexpected changes, while in orange I marked the ones that where understandable for a proxied connection.

=== Orange France through WAP GW/Proxy ===
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1
X-Nokia-CONNECTION_MODE: TCP
X-NSN-PROTOCOL-TYPE: WAP2.0
X-Nokia-BEARER: GPRS
X-Nokia-PLTF: NBG3.1.3_PP
X-Wisp: wisp2
Via: 1.1, 1.1 proxy (proxy)
Cache-Control: max-age=259200
Connection: keep-alive

=== Orange France direct connection (INTERNET) ===
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1-dir
X-Wisp: wisp2
Via: 1.1 proxy (proxy)
Cache-Control: max-age=259200
Connection: keep-alive

=== SFR through WAP GW/Proxy ===Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1
X-vfprovider: SFR
X-vfstatus: 10
X-Nokia-BEARER: GPRS
serviceControlInfo: 18+=-
x-nokia-gid: 259107281784650
X-Nokia-CONNECTION_MODE: TCP
X-Nokia-gateway-id: NWG/4.1/Build79
X-Nokia-ipaddress: 10.187.207.132
Via: 1.1 proxy.cwg.net (proxy)
X-Forwarded-For: 10.187.207.132, 10.187.207.132
Cache-Control: max-age=259200
Connection: Keep-Alive
Pragma: no-cache
X-BlueCoat-Via: 28409D05D072730C

=== SFR direct connection (INTERNET) ===
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1-dir
X-vfprovider: SFR
X-vfstatus: 10
X-Nokia-BEARER: GPRS
serviceControlInfo: 18+=-
x-nokia-gid: 259107281784650
X-Nokia-CONNECTION_MODE: TCP
X-Nokia-gateway-id: NWG/4.1/Build79
X-Nokia-ipaddress: 10.205.32.74
Via: 1.1 proxy.cwg.net (proxy)
X-Forwarded-For: 10.205.32.74, 10.205.32.74
Cache-Control: max-age=259200
Connection: Keep-Alive
Pragma: no-cache
X-BlueCoat-Via: DFF4C47D046B9013

=== Bouygues through WAP GW/proxy ===
TE: deflate,gzip;q=0.3
Connection: TE, close
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
Host: m.mobiclip.net
User-Agent: HeaderValidator/1.1

=== Bouygues direct connection (INTERNET) ===
TE: deflate,gzip;q=0.3
Connection: TE, close
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1-dir

In France we can see there is one operator, Bouygues that preservers the HTTP headers intact, probably having a better performance than SFR and Orange which add a lot of useless information.

Looking at the "new" headers added by Orange and SFR, the first question that arises is, do we really need to know the information below? What for?

X-NSN-PROTOCOL-TYPE: WAP2.0
X-Nokia-PLTF: NBG3.1.3_PP
X-Wisp: wisp2
Via: 1.1, 1.1 proxy (proxy)
X-vfprovider: SFR
X-vfstatus: 10
x-nokia-gid: 259107281784650
X-Nokia-CONNECTION_MODE: TCP
X-Nokia-gateway-id: NWG/4.1/Build79
X-Nokia-ipaddress: 10.205.32.74
Via: 1.1 proxy.cwg.net (proxy)
X-Forwarded-For: 10.205.32.74, 10.205.32.74
X-BlueCoat-Via: DFF4C47D046B9013

What is the purpose of wasting GW memory and CPU cycles adding this? Do we really need to know our device uses WAP2.0 or TCP? Or the Nokia GW ID or the Blue-Coat proxy ID? What for? As we will see in the future posts the variety of data across the main mobile operators is so big that we can conclude that this HTTP noise can´t be of use for anyone.

The surprising part is that, especially in the case of SFR, all the headers are also added by the transparent proxy in Internet connection. While in the case of Orange we see that the number of headers has been dramatically reduced.

I would assume that SFR is adding the transparent proxy "in front" of the standard Nokia GW, routing all Internet connections through it and later through the BlueCoat. Good for Nokia, as that sounds like they would need a lot of HW and licenses!!. While Orange France seams to follow a more sensible approach redirecting the Internet connections to the "WISP2" proxy which might be in charge of the useful header enrichment.

That´s all for now. Next time we´ll have a look at how the Italian Mobile Operators deal with the header enrichment.

Android embeded certificates

2010-09-03T20:20:00.000+02:00

Testing an application I wanted to verify the Root CAs embedded in an Android phone. After some searches the procedure has been easier than suspected. (For this test I used a WinXP SP3 with Java version 1.6.0_13). This what you should do to repeat it:

1) Install the Android USB Driver:
Download the Android SDK Starter package at http://developer.android.com/sdk/index.html, execute it, uncheck al components and mark the "USB Drives". Now you should have a new folder called "usb_driver"

2) In your Android phone go to Settings => Applications => Development and check "USB Debugging"

3) Connect the phone to the computer and when requested to install the required drivers choose the folder "usb_driver"

4) Go to the folder tools and in a console run
adb devices
That should display the serial number of the device you have connected. If that fails unplug and plug the device (you are in a Windows box my friend!)
5) Run
adb pull /system/etc/security/cacerts.bks cacerts.bks
to get the Root CA keystore in your computer
6) To be able to deal with that keystore you need the jar http://bouncycastle.org/download/bcprov-jdk16-141.jar on $JAVA_HOME/jre/lib/ext/
Now you can just run:
keytool -keystore cacerts.bks -storetype BKS -provider org.bouncycastle.jce.provider.BouncyCastleProvider -storepass changeit -list -v
to display the installed Root CAs

If you want to skip it I copy below the ones I found in the Nexus One and Magic:

Nexus One Root CAs:
Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority
Issuer: C=US,O=Equifax Secure Inc.,CN=Equifax Secure Global eBusiness CA-1
Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority - G2,OU=(c) 1998 VeriSign\, Inc. - For authorized use only,OU=VeriSign Trust Network
Issuer: C=IL,O=StartCom Ltd.,OU=StartCom Certification Authority,CN=StartCom Extended Validation Server CA
Issuer: C=PL,O=Unizeto Sp. z o.o.,CN=Certum CA
Issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert Assured ID Root CA
Issuer: C=HU,L=Budapest,O=NetLock Halozatbiztonsagi Kft.,OU=Tanusitvanykiadok,CN=NetLock Expressz (Class C) Tanusitvanykiado
Issuer: C=US,ST=UT,L=Salt Lake City,O=The USERTRUST Network,OU=http://www.usertrust.com,CN=UTN-USERFirst-Hardware
Issuer: C=BM,O=QuoVadis Limited,OU=Root Certification Authority,CN=QuoVadis Root Certification Authority
Issuer: C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=(c) 2006 VeriSign\, Inc. - For authorized use only,CN=VeriSign Class 3 Public Primary Certification Authority - G5
Issuer: C=HU,L=Budapest,O=NetLock Halozatbiztonsagi Kft.,OU=Tanusitvanykiadok,CN=NetLock Uzleti (Class B) Tanusitvanykiado
Issuer: L=ValiCert Validation Network,O=ValiCert\, Inc.,OU=ValiCert Class 1 Policy Validation Authority,CN=http://www.valicert.com/,E=info@valicert.com
Issuer: C=US,O=Equifax,OU=Equifax Secure Certificate Authority
Issuer: C=EU,O=AC Camerfirma SA CIF A82743287,OU=http://www.chambersign.org,CN=Chambers of Commerce Root
Issuer: C=US,O=Entrust.net,OU=www.entrust.net/CPS incorp. by ref. (limits liab.),OU=(c) 1999 Entrust.net Limited,CN=Entrust.net Secure Server Certification Authority
Issuer: C=US,O=Equifax Secure Inc.,CN=Equifax Secure eBusiness CA-1
Issuer: C=DE,ST=Hamburg,L=Hamburg,O=TC TrustCenter for Security in Data Networks GmbH,OU=TC TrustCenter Class 2 CA,E=certificate@trustcenter.de
Issuer: C=US,O=Starfield Technologies\, Inc.,OU=Starfield Class 2 Certification Authority
Issuer: C=DE,ST=Hamburg,L=Hamburg,O=TC TrustCenter for Security in Data Networks GmbH,OU=TC TrustCenter Class 3 CA,E=certificate@trustcenter.de
Issuer: C=US,O=The Go Daddy Group\, Inc.,OU=Go Daddy Class 2 Certification Authority
Issuer: C=DE,O=TC TrustCenter GmbH,OU=TC TrustCenter Universal CA,CN=TC TrustCenter Universal CA I
Issuer: C=TW,O=Government Root Certification Authority
Issuer: C=US,ST=UT,L=Salt Lake City,O=The USERTRUST Network,OU=http://www.usertrust.com,CN=UTN - DATACorp SGC
Issuer: C=ch,O=Swisscom,OU=Digital Certificate Services,CN=Swisscom Root CA 1
Issuer: C=ES,O=FNMT,OU=FNMT Clase 2 CA
Issuer: C=DE,O=Deutsche Telekom AG,OU=T-TeleSec Trust Center,CN=Deutsche Telekom Root CA 2
Issuer: C=ZA,ST=Western Cape,L=Cape Town,O=Thawte Consulting cc,OU=Certification Services Division,CN=Thawte Server CA,E=server-certs@thawte.com
Issuer: C=US,O=Digital Signature Trust,OU=DST ACES,CN=DST ACES CA X6
Issuer: C=US,O=GTE Corporation,OU=GTE CyberTrust Solutions\, Inc.,CN=GTE CyberTrust Global Root
Issuer: C=US,ST=UT,L=Salt Lake City,O=The USERTRUST Network,OU=http://www.usertrust.com,CN=UTN-USERFirst-Network Applications
Issuer: C=FR,O=Certplus,CN=Class 2 Primary CA
Issuer: O=Entrust.net,OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.),OU=(c) 1999 Entrust.net Limited,CN=Entrust.net Certification Authority (2048)
Issuer: C=JP,O=Japan Certification Services\, Inc.,CN=SecureSign RootCA1
Issuer: C=DK,O=TDC Internet,OU=TDC Internet Root CA
Issuer: C=ES,L=C/ Muntaner 244 Barcelona,CN=Autoridad de Certificacion Firmaprofesional CIF A62634068,E=ca@firmaprofesional.com
Issuer: C=SE,O=AddTrust AB,OU=AddTrust External TTP Network,CN=AddTrust External CA Root
Issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert Global Root CA
Issuer: OU=GlobalSign Root CA - R2,O=GlobalSign,CN=GlobalSign
Issuer: C=NL,O=Staat der Nederlanden,CN=Staat der Nederlanden Root CA
Issuer: C=ZA,ST=Western Cape,L=Cape Town,O=Thawte Consulting cc,OU=Certification Services Division,CN=Thawte Premium Server CA,E=premium-server@thawte.com
Issuer: OU=Copyright (c) 1997 Microsoft Corp.,OU=Microsoft Corporation,CN=Microsoft Root Authority
Issuer: C=IL,O=StartCom Ltd.,OU=Secure Digital Certificate Signing,CN=StartCom Certification Authority
Issuer: C=US,O=Entrust\, Inc.,OU=www.entrust.net/CPS is incorporated by reference,OU=(c) 2006 Entrust\, Inc.,CN=Entrust Root Certification Authority
Issuer: C=DE,O=TC TrustCenter GmbH,OU=TC TrustCenter Class 2 CA,CN=TC TrustCenter Class 2 CA II
Issuer: C=US,O=America Online Inc.,CN=America Online Root Certification Authority 1
Issuer: L=ValiCert Validation Network,O=ValiCert\, Inc.,OU=ValiCert Class 2 Policy Validation Authority,CN=http://www.valicert.com/,E=info@valicert.com
Issuer: C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)06,CN=VeriSign Class 3 Extended Validation SSL SGC CA
Issuer: C=BE,O=GlobalSign nv-sa,OU=Root CA,CN=GlobalSign Root CA
Issuer: C=HU,ST=Hungary,L=Budapest,O=NetLock Halozatbiztonsagi Kft.,OU=Tanusitvanykiadok,CN=NetLock Kozjegyzoi (Class A) Tanusitvanykiado
Issuer: C=US,O=Entrust\, Inc.,OU=AND ADDITIONAL TERMS GOVERNING USE AND RELIANCE,OU=CPS CONTAINS IMPORTANT LIMITATIONS OF WARRANTIES AND LIABILITY,OU=www.entrust.net/CPS is incorporated by reference,OU=(c) 2008 Entrust\, Inc.,CN=Entrust Certification Authority - L1B
Issuer: C=FI,O=Sonera,CN=Sonera Class2 CA
Issuer: C=JP,O=SECOM Trust.net,OU=Security Communication RootCA1
Issuer: C=BM,O=QuoVadis Limited,CN=QuoVadis Root CA 3
Issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert High Assurance EV Root CA
Issuer: L=ValiCert Validation Network,O=ValiCert\, Inc.,OU=ValiCert Class 3 Policy Validation Authority,CN=http://www.valicert.com/,E=info@valicert.com
Issuer: C=BM,O=QuoVadis Limited,CN=QuoVadis Root CA 2

Magic:
Issuer: C=HU,ST=Hungary,L=Budapest,O=NetLock Halozatbiztonsagi Kft.,OU=Tanusitvanykiadok,CN=NetLock Kozjegyzoi (Class A) Tanusitvanykiado
Issuer: C=FI,O=Sonera,CN=Sonera Class2 CA
Issuer: C=JP,O=SECOM Trust.net,OU=Security Communication RootCA1
Issuer: C=US,O=GTE Corporation,CN=GTE CyberTrust Root
Issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert High Assurance EV Root CA
Issuer: L=ValiCert Validation Network,O=ValiCert\, Inc.,OU=ValiCert Class 3 Policy Validation Authority,CN=http://www.valicert.com/,E=info@valicert.com
Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority
Issuer: C=US,O=Equifax Secure Inc.,CN=Equifax Secure Global eBusiness CA-1
Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority - G2,OU=(c) 1998 VeriSign\, Inc. - For authorized use only,OU=VeriSign Trust Network
Issuer: C=PL,O=Unizeto Sp. z o.o.,CN=Certum CA
Issuer: C=DE,ST=Hamburg,L=Hamburg,O=TC TrustCenter for Security in Data Networks GmbH,OU=TC TrustCenter Class 2 CA,E=certificate@trustcenter.de
Issuer: C=US,O=Starfield Technologies\, Inc.,OU=Starfield Class 2 Certification Authority
Issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert Assured ID Root CA
Issuer: C=US,O=The Go Daddy Group\, Inc.,OU=Go Daddy Class 2 Certification Authority
Issuer: C=HU,L=Budapest,O=NetLock Halozatbiztonsagi Kft.,OU=Tanusitvanykiadok,CN=NetLock Expressz (Class C) Tanusitvanykiado
Issuer: C=TW,O=Government Root Certification Authority
Issuer: C=HU,L=Budapest,O=NetLock Halozatbiztonsagi Kft.,OU=Tanusitvanykiadok,CN=NetLock Uzleti (Class B) Tanusitvanykiado
Issuer: C=ES,O=FNMT,OU=FNMT Clase 2 CA
Issuer: C=US,O=Equifax,OU=Equifax Secure Certificate Authority
Issuer: C=US,O=Digital Signature Trust,OU=DST ACES,CN=DST ACES CA X6
Issuer: C=DE,ST=Hamburg,L=Hamburg,O=TC TrustCenter for Security in Data Networks GmbH,OU=TC TrustCenter Class 3 CA,E=certificate@trustcenter.de
Issuer: C=US,ST=UT,L=Salt Lake City,O=The USERTRUST Network,OU=http://www.usertrust.com,CN=UTN-USERFirst-Hardware
Issuer: C=FR,O=Certplus,CN=Class 2 Primary CA
Issuer: C=US,ST=UT,L=Salt Lake City,O=The USERTRUST Network,OU=http://www.usertrust.com,CN=UTN - DATACorp SGC
Issuer: C=US,O=RSA Data Security\, Inc.,OU=Secure Server Certification Authority
Issuer: C=ES,L=C/ Muntaner 244 Barcelona,CN=Autoridad de Certificacion Firmaprofesional CIF A62634068,E=ca@firmaprofesional.com
Issuer: C=DE,O=Deutsche Telekom AG,OU=T-TeleSec Trust Center,CN=Deutsche Telekom Root CA 2
Issuer: C=ES,ST=BARCELONA,L=BARCELONA,O=IPS Seguridad CA,OU=Certificaciones,CN=IPS SERVIDORES,E=ips@mail.ips.es
Issuer: OU=GlobalSign Root CA - R2,O=GlobalSign,CN=GlobalSign
Issuer: C=US,O=GTE Corporation,OU=GTE CyberTrust Solutions\, Inc.,CN=GTE CyberTrust Global Root
Issuer: L=ValiCert Validation Network,O=ValiCert\, Inc.,OU=ValiCert Class 1 Policy Validation Authority,CN=http://www.valicert.com/,E=info@valicert.com
Issuer: OU=Copyright (c) 1997 Microsoft Corp.,OU=Microsoft Corporation,CN=Microsoft Root Authority
Issuer: C=SE,O=AddTrust AB,OU=AddTrust External TTP Network,CN=AddTrust External CA Root
Issuer: C=EU,O=AC Camerfirma SA CIF A82743287,OU=http://www.chambersign.org,CN=Chambers of Commerce Root
Issuer: C=US,O=Entrust.net,OU=www.entrust.net/CPS incorp. by ref. (limits liab.),OU=(c) 1999 Entrust.net Limited,CN=Entrust.net Secure Server Certification Authority
Issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert Global Root CA
Issuer: C=US,O=Equifax Secure Inc.,CN=Equifax Secure eBusiness CA-1
Issuer: C=ch,O=Swisscom,OU=Digital Certificate Services,CN=Swisscom Root CA 1
Issuer: C=ZA,ST=Western Cape,L=Cape Town,O=Thawte Consulting cc,OU=Certification Services Division,CN=Thawte Server CA,E=server-certs@thawte.com
Issuer: C=US,ST=UT,L=Salt Lake City,O=The USERTRUST Network,OU=http://www.usertrust.com,CN=UTN-USERFirst-Network Applications
Issuer: C=JP,O=Japan Certification Services\, Inc.,CN=SecureSign RootCA1
Issuer: C=DK,O=TDC Internet,OU=TDC Internet Root CA
Issuer: C=NL,O=Staat der Nederlanden,CN=Staat der Nederlanden Root CA
Issuer: C=IL,ST=Israel,L=Eilat,O=StartCom Ltd.,OU=CA Authority Dep.,CN=Free SSL Certification Authority,E=admin@startcom.org
Issuer: C=ZA,ST=Western Cape,L=Cape Town,O=Thawte Consulting cc,OU=Certification Services Division,CN=Thawte Premium Server CA,E=premium-server@thawte.com
Issuer: C=US,O=America Online Inc.,CN=America Online Root Certification Authority 1
Issuer: L=ValiCert Validation Network,O=ValiCert\, Inc.,OU=ValiCert Class 2 Policy Validation Authority,CN=http://www.valicert.com/,E=info@valicert.com
Issuer: C=BE,O=GlobalSign nv-sa,OU=Root CA,CN=GlobalSign Root CA

Main sources:
http://wiki.cacert.org/ImportRootCert#Android_Phones
http://developer.android.com/sdk/index.html

Orange Spain privacy misconfiguration fixed!

2010-09-01T08:32:00.000+02:00

I`m just being informed by"Anonymous" that the issue with the headers in Orange Spain has been fixed. I copy below a recent trace where the MSISDN is not being added anymore:

accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
accept-charset: iso-8859-1,utf-8
accept-language: en-us,en;q=0.5
user-agent: HeaderValidator/1.1
x-up-subno: {REMOVED}
X-Forwarded-For: 213.30.40.121
Cache-Control: max-stale=0
Connection: Keep-Alive
X-BlueCoat-Via: 4A19C93B98112ACC

I see they also removed some unnecessary headers (more on this in a future post)
The Full Disclosure Mailing List and twitter managed to caught their attention.
Another example that responsible disclosure is not always enough.

Orange Spain disclosing user phone number

2010-08-29T15:36:00.000+02:00

I'm currently assessing how mobile operators modify and enrich HTTP headers. I´ve already analyzed the main operators in France, Germany, Italy, Spain and UK with very interesting results I´ll publish soon.

The focus of the study is double, first, check how users are identified when using mobile connections to browse the web and second, the modifications that the operators do to the HTTP headers like the User-Agent, Accept, Accept-Encoding...

Regarding user identification mobile operators will normally have two methods depending on the site that the user is accessing. For internal trusted sites they will add the user MSISDN (the phone number) in an HTTP header like x-up-calling-line-id, x-up-subno, x-nokia-msisdn or a proprietary one, while for the rest, and in order to protect user's identity, they will add a temporary ID instead. That will help the web site to track the user activity during a browsing session but will prevent the web site from fully identifying the user.

During the assessment I found that Orange Spain is adding the user MSISDN in any HTTP request sent in its network. This means that it is really simple to get the user phone number from an Orange Spain user. On one hand, I saw that Orange Spain uses the header x-up-calling-line-id to add a user temporary ID that changes every 24h but I also found that in any HTTP request they will add the user phone number in the header X-Network-info.

I copy below an example of the headers where I removed some information. In green there are the headers added by my crawler while in red you can see the extra headers added by the Orange Spain WAP Gateway:

Host: {REMOVED}

TE: deflate,gzip;q=0.3

Accept: text/html, text/vnd.wap.wml, application/vnd.wap.html+xml, application/xhtml+xml, application/vnd.wap.xhtml+xml, text/x-wap.wml, text/x-hdml, text/vnd.sun.j2me.app-descriptor, application/java-archive, application/octet-stream, image/png, image/gif, image/jpg, image/jpeg, */*, text/x-vcard, text/x-vcalendar, image/vnd.wap.wbmpAccept-Charset: iso-8859-1,utf-8

Accept-Language: en-us,en;q=0.5

User-Agent: HeaderValidator/1.1

Content-length: 0

Via: WTP/1.1 nwg2 (Nokia WAP Gateway 4.1/CD21/4.1.116)

X-Network-info: CSD,34xxxxxxxxx,unsecured

X-Nokia-CONNECTION_MODE: TCP

X-Nokia-BEARER: CSD

X-Nokia-GATEWAY_ID: NWG/4.1/Build116

x-nokia.wia.accept.original: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,image/png,image/gif,image/jpg,image/jpeg,*/*,text/x-vCard,text/x-vCalendar,image/vnd.wap.wbmp

Connection: close

x-up-calling-line-id:{REMOVED}

I notified Orange Spain more than a month ago regarding the misconfiguration and its effects on their own customers but unfortunately it is still there.

If you are a user of Orange Spain have in mind that every web site you access with your mobile phone will get your phone number. Don`t be surprised if you start receiving SMS SPAM or unsolicited calls!

Generic OIDs for openssl asn1parse

2010-08-24T19:29:00.000+02:00

As a follow up of my previous post on Microsoft OIDs I add a list of the most common OIDs found in http://www.rsa.com/products/bsafe/documentation/sslc251html/group__AD__COMMON__OIDS.html
I add them in a format ready for openssl

0 undef Undefined
0.9.2342.19200300.100.1.1 userID User Identifier
0.9.2342.19200300.100.1.25 domainComponent Domain Component
1.2.643.2.2.24 gostR3411WithGost GOST
1.2.840.10040.4.1 dsa DSA
1.2.840.10040.4.3 dsaWithSHA1 Digital Signature Algorithm (DSA) with Secure Hash Algorithm 1 (SHA1)
1.2.840.10045.2.1 ecc Elliptic Curve Cryptography (ECC)
1.2.840.10045.4.1 ECDSAwithSHA1 Elliptic Curve DSA with SHA1
1.2.840.113533.7.66.10 cast5_cbc CAST Cipher Block Chaining (CBC)
1.2.840.113533.7.66.12 pbeWithMD5AndCast5_CBC CAST MD5 CBC
1.2.840.113549 rsadsi RSA Data Security Inc.
1.2.840.113549.1 pkcs Public Key Cryptography Standards (PKCS)
1.2.840.113549.1.1.1 rsaEncryption RSA Encryption
1.2.840.113549.1.1.2 md2WithRSAEncryption MD2 with RSA encryption
1.2.840.113549.1.1.4 md5WithRSAEncryption MD5 with RSA encryption
1.2.840.113549.1.1.7 rsaes_oaep RSAES Optimal Asymmetric Encryption Padding (OAEP)
1.2.840.113549.1.1.8 id_mgf Mask generation function OAEP padding
1.2.840.113549.1.1.9 id_pspecified Parameters source function OAEP padding
1.2.840.113549.1.3 pkcs3 PKCS #3
1.2.840.113549.1.3.1 dhKeyAgreement Diffie-Hellman key agreement
1.2.840.113549.1.5.1 pbeWithMD2AndDES_CBC Password Based Encryption algorithm with MD2 and DES_CBC
1.2.840.113549.1.5.11 pbeWithSHA1AndRC2_CBC Password Based Encryption algorithm with SHA1 and RC2_CBC
1.2.840.113549.1.5.12 pbeWithSHA1AndRC4 Password Based Encryption algorithm with SHA1 and RC4
1.2.840.113549.1.5.3 pbeWithMD5AndDES_CBC Password Based Encryption algorithm with MD5 and DES_CBC
1.2.840.113549.1.7 pkcs7 PKCS #7
1.2.840.113549.1.7.1 pkcs7_data PKCS #7 data
1.2.840.113549.1.7.2 pkcs7_signed PKCS #7 signed data
1.2.840.113549.1.7.3 pkcs7_enveloped PKCS #7 enveloped data
1.2.840.113549.1.7.4 pkcs7_signedAndEnveloped PKCS #7 signed and enveloped data
1.2.840.113549.1.7.5 pkcs7_digest PKCS #7 digest data
1.2.840.113549.1.7.6 pkcs7_encrypted PKCS #7 encrypted data
1.2.840.113549.1.9 pkcs9 PKCS #9
1.2.840.113549.1.9.1 pkcs9_emailAddress PKCS #9 e-mail address
1.2.840.113549.1.9.2 pkcs9_unstructuredName PKCS #9 unstructured name
1.2.840.113549.1.9.3 pkcs9_contentType PKCS #9 content type
1.2.840.113549.1.9.4 pkcs9_messageDigest PKCS #9 message digest
1.2.840.113549.1.9.5 pkcs9_signingTime PKCS #9 signing time
1.2.840.113549.1.9.6 pkcs9_countersignature PKCS #9 counter signature
1.2.840.113549.1.9.7 pkcs9_challengePassword PKCS #9 challenge password
1.2.840.113549.1.9.8 pkcs9_unstructuredAddress PKCS #9 unstructured address
1.2.840.113549.1.9.9 pkcs9_extCertAttributes PKCS #9 extended certificate attributes
1.2.840.113549.2.2 md2 MD2
1.2.840.113549.2.5 md5 MD5
1.2.840.113549.3.11.1 rc6_ebc RC6 Electronic Code Book (ECB)
1.2.840.113549.3.11.2 rc6_cbc RC6 CBC
1.2.840.113549.3.11.3 rc6_ofb128 RC6 128-bit Output Feedback (OFB)
1.2.840.113549.3.11.4 rc6_cfb128 RC6 128-bit Cipher Feedback (CFB)
1.2.840.113549.3.2 rc2_cbc RC2 with CBC
1.2.840.113549.3.4 rc4 RC4
1.2.840.113549.3.7 des_ede3_cbc DES with EDE3 CBC
1.2.840.113549.3.9 rc5_cbc RC5 CBC
1.2.840.1135491.1.1.5 sha1WithRSAEncryption SHA1 with RSA encryption
1.3.132.0.1 sigECDSAec239a01 Koblitz Elliptic Curve over F2m
1.3.132.0.2 sigECDSAec163b01 Random Elliptic Curve over F2m
1.3.132.0.3 sigECDSAec163a01 Koblitz Elliptic Curve over F2m
1.3.14.3.2 algorithm ALGORITHM
1.3.14.3.2.12 dsa_2 DSA
1.3.14.3.2.13 dsaWithSHA DSA with SHA
1.3.14.3.2.15 shaWithRSAEncryption SHA with RSA encryption
1.3.14.3.2.17 des_ede DES EDE
1.3.14.3.2.18 sha SHA
1.3.14.3.2.26 sha1 SHA1
1.3.14.3.2.27 dsaWithSHA1_2 DSA with SHA1
1.3.14.3.2.29 sha1WithRSA SHA1 with RSA
1.3.14.3.2.3 md5WithRSA MD5 RSA
1.3.14.3.2.6 des_ecb DES ECB
1.3.14.3.2.7 des_cbc DES CBC
1.3.14.3.2.8 des_ofb64 DES with 64-bit OFB
1.3.14.3.2.9 des_cfb64 DES with 64-bit CFB
1.3.36.3.2.1 ripemd160 RIPMD-160
1.3.36.3.3.1.2 ripemd160WithRSA RSA signature with RIPMD-160
1.3.6.1.4.1.311.10.3.3 ms_sgc Microsoft Server Gated Cryptography
1.3.6.1.5.5.7.3 id_kp Key purpose identifier
1.3.6.1.5.5.7.3.1 serverAuth Server authentication key usage extension
1.3.6.1.5.5.7.3.2 clientAuth Client authentication key usage extension
1.3.6.1.5.5.7.3.3 codeSigning Code signing key usage extension
1.3.6.1.5.5.7.3.4 emailProtection E-mail protection key usage extension
1.3.6.1.5.5.7.3.5 ipsecEndSystem IPSec end system key usage extension
1.3.6.1.5.5.7.3.6 ipsecTunnel IPSec tunnel key usage extension
1.3.6.1.5.5.7.3.7 ipsecUser IPSec user key usage extension
1.3.6.1.5.5.7.3.8 timeStamping Time stamping key usage extension
1.3.6.1.5.5.7.3.9 ocspSigning Online Certificate Status Protocol (OCSP) signing key usage extension
2.16.840.1.101.3.4.1 nistAlgorithms1 NIST-certified algorithms
2.16.840.1.101.3.4.1.1 aes128_ecb AES 128-bit ECB
2.16.840.1.101.3.4.1.2 aes128_cbc AES 128-bit CBC
2.16.840.1.101.3.4.1.21 aes192_ecb AES 192-bit ECB
2.16.840.1.101.3.4.1.22 aes192_cbc AES 192-bit CBC
2.16.840.1.101.3.4.1.23 aes192_ofb AES 192-bit OFB
2.16.840.1.101.3.4.1.24 aes192_cfb AES 192-bit CFB
2.16.840.1.101.3.4.1.3 aes128_ofb AES 128-bit OFB
2.16.840.1.101.3.4.1.4 aes128_cfb AES 128-bit CFB
2.16.840.1.101.3.4.1.41 aes256_ecb AES 256-bit ECB
2.16.840.1.101.3.4.1.42 aes256_cbc AES 256-bit CBC
2.16.840.1.101.3.4.1.43 aes256_ofb AES 256-bit OFB
2.16.840.1.101.3.4.1.44 aes256_cfb AES 256-bit CFB
2.16.840.1.101.3.4.2.1 sha256 SHA256
2.16.840.1.101.3.4.2.2 sha384 SHA384
2.16.840.1.101.3.4.2.3 sha512 SHA512
2.16.840.1.113730 netscape Netscape
2.16.840.1.113730.1 netscape_cert_extension Netscape certificate extension
2.16.840.1.113730.1.1 netscape_cert_type Netscape certificate type
2.16.840.1.113730.1.12 netscape_ssl_server_name Netscape SSL server name
2.16.840.1.113730.1.13 netscape_comment Netscape comment
2.16.840.1.113730.1.2 netscape_base_url Netscape base URL
2.16.840.1.113730.1.3 netscape_revocation_url Netscape revocation URL
2.16.840.1.113730.1.4 netscape_ca_revocation_url Netscape Certification Authority (CA) revocation URL
2.16.840.1.113730.1.7 netscape_renewal_url Netscape renewal URL
2.16.840.1.113730.1.8 netscape_ca_policy_url Netscape CA policy URL
2.16.840.1.113730.2 netscape_data_type Netscape data type
2.16.840.1.113730.2.5 netscape_cert_sequence Netscape certificate sequence
2.16.840.1.113730.4.1 ns_sgc Netscape Server Gated Cryptography
2.5 X500 X.500
2.5.29 id_ce Certificate extension identifier
2.5.29.14 subject_key_identifier X.509 version 3 subject key identifier
2.5.29.15 key_usage X.509 version 3 key usage identifier
2.5.29.16 private_key_usage_period X.509 version 3 private key usage period
2.5.29.17 subject_alt_name X.509 version 3 subject alternative name
2.5.29.18 issuer_alt_name X.509 version 3 issuer alternative name
2.5.29.19 basic_constraints X.509 version 3 basic constraints
2.5.29.20 crl_number X.509 version 3 Certificate Revocation List (CRL) number
2.5.29.21 reasonCode X.509 version 3 CRL reason code
2.5.29.23 instruction_code X.509 version 3 CRL instruction code
2.5.29.24 invalidity_date X.509 version 3 CRL invalidity date
2.5.29.27 delta_crl_indicator X.509 version 3 CRL delta CRL indicator
2.5.29.28 issuing_distribution_point X.509 version 3 CRL issuing distribution point
2.5.29.30 name_constraints X.509 version 3 CRL name constraints
2.5.29.30 name_constraints X.509 version 3 CRL name constraints
2.5.29.31 crl_distribution_points X.509 version 3 CRL distribution points
2.5.29.32 certificate_policies X.509 version 3 certificate policies
2.5.29.35 authority_key_identifier X.509 version 3 Authority Key Identifier
2.5.29.37 ext_key_usage X.509 version 3 extended key usage
2.5.4 X509 X.509
2.5.4.10 organizationName Organization name
2.5.4.11 organizationalUnitName Organizational unit name
2.5.4.12 title Title
2.5.4.13 description Description
2.5.4.3 commonName Common name
2.5.4.4 surname Surname
2.5.4.42 givenName Given name
2.5.4.43 initials Initials
2.5.4.44 generationQualifier Generation qualifier
2.5.4.45 uniqueIdentifier Unique identifier
2.5.4.46 dnQualifier Distinguished Name (DN) qualifier
2.5.4.5 serialNumber Serial number
2.5.4.6 countryName Country name
2.5.4.7 localityName Locality name
2.5.4.8 stateOrProvinceName State or province name
2.5.4.9 street Street
2.5.8.1.1 rsa RSA

Microsoft OIDs

2010-08-17T10:20:00.000+02:00

Doing some asn1 parsing with Openssl I came across some some specific Microsoft OID which where unknown. I found the "Object IDs associated with Microsoft cryptography" page (http://support.microsoft.com/kb/287547) with a long list of OIDs. As I wanted to use them with the Openssl asn1 parser I put them in a file (oid.txt) with the following format:

OID short_name long_name
OID2 short_name2 long_name2

so I can just run the command:
openssl asn1parse -oid oid.txt -in file

In case you ever want to use them but don´t want to spend time putting the file together, I just copy the contents of the oid.txt below.

1.3.6.1.4.1.311 Microsoft_OID Microsoft OID
1.3.6.1.4.1.311.2 Authenticode Authenticode
1.3.6.1.4.1.311.2.1.4 SPC_INDIRECT_DATA_OBJID SPC INDIRECT DATA OBJID
1.3.6.1.4.1.311.2.1.11 SPC_STATEMENT_TYPE_OBJID SPC STATEMENT TYPE OBJID
1.3.6.1.4.1.311.2.1.12 SPC_SP_OPUS_INFO_OBJID SPC SP OPUS INFO OBJID
1.3.6.1.4.1.311.2.1.15 SPC_PE_IMAGE_DATA_OBJID SPC PE IMAGE DATA OBJID
1.3.6.1.4.1.311.2.1.10 SPC_SP_AGENCY_INFO_OBJID SPC SP AGENCY INFO OBJID
1.3.6.1.4.1.311.2.1.26 SPC_MINIMAL_CRITERIA_OBJID SPC MINIMAL CRITERIA OBJID
1.3.6.1.4.1.311.2.1.27 SPC_FINANCIAL_CRITERIA_OBJID SPC FINANCIAL CRITERIA OBJID
1.3.6.1.4.1.311.2.1.28 SPC_LINK_OBJID SPC LINK OBJID
1.3.6.1.4.1.311.2.1.29 SPC_HASH_INFO_OBJID SPC HASH INFO OBJID
1.3.6.1.4.1.311.2.1.30 SPC_SIPINFO_OBJID SPC SIPINFO OBJID
1.3.6.1.4.1.311.2.1.14 SPC_CERT_EXTENSIONS_OBJID SPC CERT EXTENSIONS OBJID
1.3.6.1.4.1.311.2.1.18 SPC_RAW_FILE_DATA_OBJID SPC RAW FILE DATA OBJID
1.3.6.1.4.1.311.2.1.19 SPC_STRUCTURED_STORAGE_DATA_OBJID SPC STRUCTURED STORAGE DATA OBJID
1.3.6.1.4.1.311.2.1.20 SPC_JAVA_CLASS_DATA_OBJID SPC JAVA CLASS DATA OBJID
1.3.6.1.4.1.311.2.1.21 SPC_INDIVIDUAL_SP_KEY_PURPOSE_OBJID SPC INDIVIDUAL SP KEY PURPOSE OBJID
1.3.6.1.4.1.311.2.1.22 SPC_COMMERCIAL_SP_KEY_PURPOSE_OBJID SPC COMMERCIAL SP KEY PURPOSE OBJID
1.3.6.1.4.1.311.2.1.25 SPC_CAB_DATA_OBJID SPC CAB DATA OBJID
1.3.6.1.4.1.311.2.1.25 SPC_GLUE_RDN_OBJID SPC GLUE RDN OBJID
1.3.6.1.4.1.311.2.2 CTL_for_Software_Publishers_Trusted_CAs CTL for Software Publishers Trusted CAs
1.3.6.1.4.1.311.2.2.1 szOID_TRUSTED_CODESIGNING_CA_LIST OID TRUSTED CODESIGNING CA LIST
1.3.6.1.4.1.311.2.2.2 szOID_TRUSTED_CLIENT_AUTH_CA_LIST OID TRUSTED CLIENT AUTH CA LIST
1.3.6.1.4.1.311.2.2.3 szOID_TRUSTED_SERVER_AUTH_CA_LIST OID TRUSTED SERVER AUTH CA LIST
1.3.6.1.4.1.311.3 Time_Stamping Time Stamping
1.3.6.1.4.1.311.3.2.1 SPC_TIME_STAMP_REQUEST_OBJID SPC TIME STAMP REQUEST OBJID
1.3.6.1.4.1.311.4 Permissions Permissions
1.3.6.1.4.1.311.10 Crypto_2.0 Crypto 2.0
1.3.6.1.4.1.311.10.1 szOID_CTL OID CTL
1.3.6.1.4.1.311.10.1.1 szOID_SORTED_CTL OID SORTED CTL
1.3.6.1.4.1.311.10.2 szOID_NEXT_UPDATE_LOCATION OID NEXT UPDATE LOCATION
1.3.6.1.4.1.311.10.3.1 szOID_KP_CTL_USAGE_SIGNING OID KP CTL USAGE SIGNING
1.3.6.1.4.1.311.10.3.2 szOID_KP_TIME_STAMP_SIGNING OID KP TIME STAMP SIGNING
1.3.6.1.4.1.311.10.3.3 szOID_SERVER_GATED_CRYPTO OID SERVER GATED CRYPTO
1.3.6.1.4.1.311.10.3.3.1 szOID_SERIALIZED OID SERIALIZED
1.3.6.1.4.1.311.10.3.4 szOID_EFS_CRYPTO OID EFS CRYPTO
1.3.6.1.4.1.311.10.3.4.1 szOID_EFS_RECOVERY OID EFS RECOVERY
1.3.6.1.4.1.311.10.3.5 szOID_WHQL_CRYPTO OID WHQL CRYPTO
1.3.6.1.4.1.311.10.3.6 szOID_NT5_CRYPTO OID NT5 CRYPTO
1.3.6.1.4.1.311.10.3.7 szOID_OEM_WHQL_CRYPTO OID OEM WHQL CRYPTO
1.3.6.1.4.1.311.10.3.8 szOID_EMBEDDED_NT_CRYPTO OID EMBEDDED NT CRYPTO
1.3.6.1.4.1.311.10.3.9 szOID_ROOT_LIST_SIGNER OID ROOT LIST SIGNER
1.3.6.1.4.1.311.10.3.10 szOID_KP_QUALIFIED_SUBORDINATION OID KP QUALIFIED SUBORDINATION
1.3.6.1.4.1.311.10.3.11 szOID_KP_KEY_RECOVERY OID KP KEY RECOVERY
1.3.6.1.4.1.311.10.3.12 szOID_KP_DOCUMENT_SIGNING OID KP DOCUMENT SIGNING
1.3.6.1.4.1.311.10.4.1 szOID_YESNO_TRUST_ATTR OID YESNO TRUST ATTR
1.3.6.1.4.1.311.10.5.1 szOID_DRM OID DRM
1.3.6.1.4.1.311.10.5.2 szOID_DRM_INDIVIDUALIZATION OID DRM INDIVIDUALIZATION
1.3.6.1.4.1.311.10.6.1 szOID_LICENSES OID LICENSES
1.3.6.1.4.1.311.10.6.2 szOID_LICENSE_SERVER OID LICENSE SERVER
1.3.6.1.4.1.311.10.7 szOID_MICROSOFT_RDN_PREFIX OID MICROSOFT RDN PREFIX
1.3.6.1.4.1.311.10.7.1 szOID_KEYID_RDN OID KEYID RDN
1.3.6.1.4.1.311.10.8.1 szOID_REMOVE_CERTIFICATE OID REMOVE CERTIFICATE
1.3.6.1.4.1.311.10.9.1 szOID_CROSS_CERT_DIST_POINTS OID CROSS CERT DIST POINTS
1.3.6.1.4.1.311.10.10 Microsoft_CMC_OIDs Microsoft CMC OIDs
1.3.6.1.4.1.311.10.10.1 szOID_CMC_ADD_ATTRIBUTES OID CMC ADD ATTRIBUTES
1.3.6.1.4.1.311.10.11 Microsoft_certificate_property_OIDs Microsoft certificate property OIDs
1.3.6.1.4.1.311.10.11. szOID_CERT_PROP_ID_PREFIX OID CERT PROP ID PREFIX
1.3.6.1.4.1.311.10.12 CryptUI CryptUI
1.3.6.1.4.1.311.10.12.1 szOID_ANY_APPLICATION_POLICY OID ANY APPLICATION POLICY
1.3.6.1.4.1.311.12 Catalog Catalog
1.3.6.1.4.1.311.12.1.1 szOID_CATALOG_LIST OID CATALOG LIST
1.3.6.1.4.1.311.12.1.2 szOID_CATALOG_LIST_MEMBER OID CATALOG LIST MEMBER
1.3.6.1.4.1.311.12.2.1 CAT_NAMEVALUE_OBJID CAT NAMEVALUE OBJID
1.3.6.1.4.1.311.12.2.2 CAT_MEMBERINFO_OBJID CAT MEMBERINFO OBJID
1.3.6.1.4.1.311.13 Microsoft_PKCS10_OIDs Microsoft PKCS10 OIDs
1.3.6.1.4.1.311.13.1 szOID_RENEWAL_CERTIFICATE OID RENEWAL CERTIFICATE
1.3.6.1.4.1.311.13.2.1 szOID_ENROLLMENT_NAME_VALUE_PAIR OID ENROLLMENT NAME VALUE PAIR
1.3.6.1.4.1.311.13.2.2 szOID_ENROLLMENT_CSP_PROVIDER OID ENROLLMENT CSP PROVIDER
1.3.6.1.4.1.311.15 Microsoft_Java Microsoft Java
1.3.6.1.4.1.311.16 Microsoft_Outlook/Exchange Microsoft Outlook/Exchange
1.3.6.1.4.1.311.16.4 Outlook_Express Outlook Express
1.3.6.1.4.1.311.17 Microsoft_PKCS12_attributes Microsoft PKCS12 attributes
1.3.6.1.4.1.311.17.1 szOID_LOCAL_MACHINE_KEYSET OID LOCAL MACHINE KEYSET
1.3.6.1.4.1.311.18 Microsoft_Hydra Microsoft Hydra
1.3.6.1.4.1.311.19 Microsoft_ISPU_Test Microsoft ISPU Test
1.3.6.1.4.1.311.20 Microsoft_Enrollment_Infrastructure Microsoft Enrollment Infrastructure
1.3.6.1.4.1.311.20.1 szOID_AUTO_ENROLL_CTL_USAGE OID AUTO ENROLL CTL USAGE
1.3.6.1.4.1.311.20.2 szOID_ENROLL_CERTTYPE_EXTENSION OID ENROLL CERTTYPE EXTENSION
1.3.6.1.4.1.311.20.2.1 szOID_ENROLLMENT_AGENT OID ENROLLMENT AGENT
1.3.6.1.4.1.311.20.2.2 szOID_KP_SMARTCARD_LOGON OID KP SMARTCARD LOGON
1.3.6.1.4.1.311.20.2.3 szOID_NT_PRINCIPAL_NAME OID NT PRINCIPAL NAME
1.3.6.1.4.1.311.20.3 szOID_CERT_MANIFOLD OID CERT MANIFOLD
1.3.6.1.4.1.311.21 Microsoft_CertSrv_Infrastructure Microsoft CertSrv Infrastructure
1.3.6.1.4.1.311.21.1 szOID_CERTSRV_CA_VERSION OID CERTSRV CA VERSION
1.3.6.1.4.1.311.25 Microsoft_Directory_Service Microsoft Directory Service
1.3.6.1.4.1.311.25.1 szOID_NTDS_REPLICATION OID NTDS REPLICATION
1.3.6.1.4.1.311.30 IIS IIS
1.3.6.1.4.1.311.31 Windows_updates_and_service_packs Windows updates and service packs
1.3.6.1.4.1.311.31.1 szOID_PRODUCT_UPDATE OID PRODUCT UPDATE
1.3.6.1.4.1.311.40 Fonts Fonts
1.3.6.1.4.1.311.41 Microsoft_Licensing_and_Registration Microsoft Licensing and Registration
1.3.6.1.4.1.311.42 Microsoft_Corporate_PKI_(ITG) Microsoft Corporate PKI (ITG)
1.3.6.1.4.1.311.88 CAPICOM CAPICOM
1.3.6.1.4.1.311.88 szOID_CAPICOM OID CAPICOM
1.3.6.1.4.1.311.88.1 szOID_CAPICOM_VERSION OID CAPICOM VERSION
1.3.6.1.4.1.311.88.2 szOID_CAPICOM_ATTRIBUTE OID CAPICOM ATTRIBUTE
1.3.6.1.4.1.311.88.2.1 szOID_CAPICOM_DOCUMENT_NAME OID CAPICOM DOCUMENT NAME
1.3.6.1.4.1.311.88.2.2 szOID_CAPICOM_DOCUMENT_DESCRIPTION OID CAPICOM DOCUMENT DESCRIPTION
1.3.6.1.4.1.311.88.3 szOID_CAPICOM_ENCRYPTED_DATA OID CAPICOM ENCRYPTED DATA
1.3.6.1.4.1.311.88.3.1 szOID_CAPICOM_ENCRYPTED_CONTENT OID CAPICOM ENCRYPTED CONTENT
1.3.6.1.4.1.311 Microsoft_OID Microsoft OID
1.3.6.1.4.1.311.2 Authenticode Authenticode
1.3.6.1.4.1.311.2.1.4 SPC_INDIRECT_DATA_OBJID SPC INDIRECT DATA OBJID
1.3.6.1.4.1.311.2.1.11 SPC_STATEMENT_TYPE_OBJID SPC STATEMENT TYPE OBJID
1.3.6.1.4.1.311.2.1.12 SPC_SP_OPUS_INFO_OBJID SPC SP OPUS INFO OBJID
1.3.6.1.4.1.311.2.1.15 SPC_PE_IMAGE_DATA_OBJID SPC PE IMAGE DATA OBJID
1.3.6.1.4.1.311.2.1.10 SPC_SP_AGENCY_INFO_OBJID SPC SP AGENCY INFO OBJID
1.3.6.1.4.1.311.2.1.26 SPC_MINIMAL_CRITERIA_OBJID SPC MINIMAL CRITERIA OBJID
1.3.6.1.4.1.311.2.1.27 SPC_FINANCIAL_CRITERIA_OBJID SPC FINANCIAL CRITERIA OBJID
1.3.6.1.4.1.311.2.1.28 SPC_LINK_OBJID SPC LINK OBJID
1.3.6.1.4.1.311.2.1.29 SPC_HASH_INFO_OBJID SPC HASH INFO OBJID
1.3.6.1.4.1.311.2.1.30 SPC_SIPINFO_OBJID SPC SIPINFO OBJID
1.3.6.1.4.1.311.2.1.14 SPC_CERT_EXTENSIONS_OBJID SPC CERT EXTENSIONS OBJID
1.3.6.1.4.1.311.2.1.18 SPC_RAW_FILE_DATA_OBJID SPC RAW FILE DATA OBJID
1.3.6.1.4.1.311.2.1.19 SPC_STRUCTURED_STORAGE_DATA_OBJID SPC STRUCTURED STORAGE DATA OBJID
1.3.6.1.4.1.311.2.1.20 SPC_JAVA_CLASS_DATA_OBJID SPC JAVA CLASS DATA OBJID
1.3.6.1.4.1.311.2.1.21 SPC_INDIVIDUAL_SP_KEY_PURPOSE_OBJID SPC INDIVIDUAL SP KEY PURPOSE OBJID
1.3.6.1.4.1.311.2.1.22 SPC_COMMERCIAL_SP_KEY_PURPOSE_OBJID SPC COMMERCIAL SP KEY PURPOSE OBJID
1.3.6.1.4.1.311.2.1.25 SPC_CAB_DATA_OBJID SPC CAB DATA OBJID
1.3.6.1.4.1.311.2.1.25 SPC_GLUE_RDN_OBJID SPC GLUE RDN OBJID
1.3.6.1.4.1.311.2.2 CTL_for_Software_Publishers_Trusted_CAs CTL for Software Publishers Trusted CAs
1.3.6.1.4.1.311.2.2.1 szOID_TRUSTED_CODESIGNING_CA_LIST OID TRUSTED CODESIGNING CA LIST
1.3.6.1.4.1.311.2.2.2 szOID_TRUSTED_CLIENT_AUTH_CA_LIST OID TRUSTED CLIENT AUTH CA LIST
1.3.6.1.4.1.311.2.2.3 szOID_TRUSTED_SERVER_AUTH_CA_LIST OID TRUSTED SERVER AUTH CA LIST
1.3.6.1.4.1.311.3 Time_Stamping Time Stamping
1.3.6.1.4.1.311.3.2.1 SPC_TIME_STAMP_REQUEST_OBJID SPC TIME STAMP REQUEST OBJID
1.3.6.1.4.1.311.4 Permissions Permissions
1.3.6.1.4.1.311.10 Crypto_2.0 Crypto 2.0
1.3.6.1.4.1.311.10.1 szOID_CTL OID CTL
1.3.6.1.4.1.311.10.1.1 szOID_SORTED_CTL OID SORTED CTL
1.3.6.1.4.1.311.10.2 szOID_NEXT_UPDATE_LOCATION OID NEXT UPDATE LOCATION
1.3.6.1.4.1.311.10.3.1 szOID_KP_CTL_USAGE_SIGNING OID KP CTL USAGE SIGNING
1.3.6.1.4.1.311.10.3.2 szOID_KP_TIME_STAMP_SIGNING OID KP TIME STAMP SIGNING
1.3.6.1.4.1.311.10.3.3 szOID_SERVER_GATED_CRYPTO OID SERVER GATED CRYPTO
1.3.6.1.4.1.311.10.3.3.1 szOID_SERIALIZED OID SERIALIZED
1.3.6.1.4.1.311.10.3.4 szOID_EFS_CRYPTO OID EFS CRYPTO
1.3.6.1.4.1.311.10.3.4.1 szOID_EFS_RECOVERY OID EFS RECOVERY
1.3.6.1.4.1.311.10.3.5 szOID_WHQL_CRYPTO OID WHQL CRYPTO
1.3.6.1.4.1.311.10.3.6 szOID_NT5_CRYPTO OID NT5 CRYPTO
1.3.6.1.4.1.311.10.3.7 szOID_OEM_WHQL_CRYPTO OID OEM WHQL CRYPTO
1.3.6.1.4.1.311.10.3.8 szOID_EMBEDDED_NT_CRYPTO OID EMBEDDED NT CRYPTO
1.3.6.1.4.1.311.10.3.9 szOID_ROOT_LIST_SIGNER OID ROOT LIST SIGNER
1.3.6.1.4.1.311.10.3.10 szOID_KP_QUALIFIED_SUBORDINATION OID KP QUALIFIED SUBORDINATION
1.3.6.1.4.1.311.10.3.11 szOID_KP_KEY_RECOVERY OID KP KEY RECOVERY
1.3.6.1.4.1.311.10.3.12 szOID_KP_DOCUMENT_SIGNING OID KP DOCUMENT SIGNING
1.3.6.1.4.1.311.10.3.13 szOID_KP_LIFETIME_SIGNING OID KP LIFETIME SIGNING
1.3.6.1.4.1.311.10.3.14 szOID_KP_MOBILE_DEVICE_SOFTWARE OID KP MOBILE DEVICE SOFTWARE
1.3.6.1.4.1.311.10.4.1 szOID_YESNO_TRUST_ATTR OID YESNO TRUST ATTR
1.3.6.1.4.1.311.10.5.1 szOID_DRM OID DRM
1.3.6.1.4.1.311.10.5.2 szOID_DRM_INDIVIDUALIZATION OID DRM INDIVIDUALIZATION
1.3.6.1.4.1.311.10.6.1 szOID_LICENSES OID LICENSES
1.3.6.1.4.1.311.10.6.2 szOID_LICENSE_SERVER OID LICENSE SERVER
1.3.6.1.4.1.311.10.7 szOID_MICROSOFT_RDN_PREFIX OID MICROSOFT RDN PREFIX
1.3.6.1.4.1.311.10.7.1 szOID_KEYID_RDN OID KEYID RDN
1.3.6.1.4.1.311.10.8.1 szOID_REMOVE_CERTIFICATE OID REMOVE CERTIFICATE
1.3.6.1.4.1.311.10.9.1 szOID_CROSS_CERT_DIST_POINTS OID CROSS CERT DIST POINTS
1.3.6.1.4.1.311.10.10 Microsoft_CMC_OIDs Microsoft CMC OIDs
1.3.6.1.4.1.311.10.10.1 szOID_CMC_ADD_ATTRIBUTES OID CMC ADD ATTRIBUTES
1.3.6.1.4.1.311.10.11 Microsoft_certificate_property_OIDs Microsoft certificate property OIDs
1.3.6.1.4.1.311.10.11.1 szOID_CERT_PROP_ID_PREFIX OID CERT PROP ID PREFIX
1.3.6.1.4.1.311.10.12 CryptUI CryptUI
1.3.6.1.4.1.311.10.12.1 szOID_ANY_APPLICATION_POLICY OID ANY APPLICATION POLICY
1.3.6.1.4.1.311.12 Catalog Catalog
1.3.6.1.4.1.311.12.1.1 szOID_CATALOG_LIST OID CATALOG LIST
1.3.6.1.4.1.311.12.1.2 szOID_CATALOG_LIST_MEMBER OID CATALOG LIST MEMBER
1.3.6.1.4.1.311.12.2.1 CAT_NAMEVALUE_OBJID CAT NAMEVALUE OBJID
1.3.6.1.4.1.311.12.2.2 CAT_MEMBERINFO_OBJID CAT MEMBERINFO OBJID
1.3.6.1.4.1.311.13 Microsoft_PKCS10_OIDs Microsoft PKCS10 OIDs
1.3.6.1.4.1.311.13.1 szOID_RENEWAL_CERTIFICATE OID RENEWAL CERTIFICATE
1.3.6.1.4.1.311.13.2.1 szOID_ENROLLMENT_NAME_VALUE_PAIR OID ENROLLMENT NAME VALUE PAIR
1.3.6.1.4.1.311.13.2.2 szOID_ENROLLMENT_CSP_PROVIDER OID ENROLLMENT CSP PROVIDER
1.3.6.1.4.1.311.13.2.3 szOID_OS_VERSION OID OS VERSION
1.3.6.1.4.1.311.15 Microsoft_Java Microsoft Java
1.3.6.1.4.1.311.16 Microsoft_Outlook/Exchange Microsoft Outlook/Exchange
1.3.6.1.4.1.311.16.4 szOID_MICROSOFT_Encryption_Key_Preference OID MICROSOFT Encryption Key Preference
1.3.6.1.4.1.311.17 Microsoft_PKCS12_attributes Microsoft PKCS12 attributes
1.3.6.1.4.1.311.17.1 szOID_LOCAL_MACHINE_KEYSET OID LOCAL MACHINE KEYSET
1.3.6.1.4.1.311.18 Microsoft_Hydra Microsoft Hydra
1.3.6.1.4.1.311.18.1 szOID_PKIX_LICENSE_INFO OID PKIX LICENSE INFO
1.3.6.1.4.1.311.18.2 szOID_PKIX_MANUFACTURER OID PKIX MANUFACTURER
1.3.6.1.4.1.311.18.3 szOID_PKIX_MANUFACTURER_MS_SPECIFIC OID PKIX MANUFACTURER MS SPECIFIC
1.3.6.1.4.1.311.18.4 szOID_PKIX_HYDRA_CERT_VERSION OID PKIX HYDRA CERT VERSION
1.3.6.1.4.1.311.18.5 szOID_PKIX_LICENSED_PRODUCT_INFO OID PKIX LICENSED PRODUCT INFO
1.3.6.1.4.1.311.18.6 szOID_PKIX_MS_LICENSE_SERVER_INFO OID PKIX MS LICENSE SERVER INFO
1.3.6.1.4.1.311.18.7 szOID_PKIS_PRODUCT_SPECIFIC_OID OID PKIS PRODUCT SPECIFIC OID
1.3.6.1.4.1.311.18.8 szOID_PKIS_TLSERVER_SPK_OID OID PKIS TLSERVER SPK OID
1.3.6.1.4.1.311.19 Microsoft_ISPU_Test Microsoft ISPU Test
1.3.6.1.4.1.311.20 Microsoft_Enrollment_Infrastructure Microsoft Enrollment Infrastructure
1.3.6.1.4.1.311.20.1 szOID_AUTO_ENROLL_CTL_USAGE OID AUTO ENROLL CTL USAGE
1.3.6.1.4.1.311.20.2 szOID_ENROLL_CERTTYPE_EXTENSION OID ENROLL CERTTYPE EXTENSION
1.3.6.1.4.1.311.20.2.1 szOID_ENROLLMENT_AGENT OID ENROLLMENT AGENT
1.3.6.1.4.1.311.20.2.2 szOID_KP_SMARTCARD_LOGON OID KP SMARTCARD LOGON
1.3.6.1.4.1.311.20.2.3 szOID_NT_PRINCIPAL_NAME OID NT PRINCIPAL NAME
1.3.6.1.4.1.311.20.3 szOID_CERT_MANIFOLD OID CERT MANIFOLD
1.3.6.1.4.1.311.21 Microsoft_CertSrv_Infrastructure Microsoft CertSrv Infrastructure
1.3.6.1.4.1.311.21.1 szOID_CERTSRV_CA_VERSION OID CERTSRV CA VERSION
1.3.6.1.4.1.311.21.2 szOID_CERTSRV_PREVIOUS_CERT_HASH OID CERTSRV PREVIOUS CERT HASH
1.3.6.1.4.1.311.21.3 szOID_CRL_VIRTUAL_BASE OID CRL VIRTUAL BASE
1.3.6.1.4.1.311.21.4 szOID_CRL_NEXT_PUBLISH OID CRL NEXT PUBLISH
1.3.6.1.4.1.311.21.5 szOID_KP_CA_EXCHANGE OID KP CA EXCHANGE
1.3.6.1.4.1.311.21.6 szOID_KP_KEY_RECOVERY_AGENT OID KP KEY RECOVERY AGENT
1.3.6.1.4.1.311.21.7 szOID_CERTIFICATE_TEMPLATE OID CERTIFICATE TEMPLATE
1.3.6.1.4.1.311.21.8 szOID_ENTERPRISE_OID_ROOT OID ENTERPRISE OID ROOT
1.3.6.1.4.1.311.21.9 szOID_RDN_DUMMY_SIGNER OID RDN DUMMY SIGNER
1.3.6.1.4.1.311.21.10 szOID_APPLICATION_CERT_POLICIES OID APPLICATION CERT POLICIES
1.3.6.1.4.1.311.21.11 szOID_APPLICATION_POLICY_MAPPINGS OID APPLICATION POLICY MAPPINGS
1.3.6.1.4.1.311.21.12 szOID_APPLICATION_POLICY_CONSTRAINTS OID APPLICATION POLICY CONSTRAINTS
1.3.6.1.4.1.311.21.13 szOID_ARCHIVED_KEY_ATTR OID ARCHIVED KEY ATTR
1.3.6.1.4.1.311.21.14 szOID_CRL_SELF_CDP OID CRL SELF CDP
1.3.6.1.4.1.311.21.15 szOID_REQUIRE_CERT_CHAIN_POLICY OID REQUIRE CERT CHAIN POLICY
1.3.6.1.4.1.311.21.16 szOID_ARCHIVED_KEY_CERT_HASH OID ARCHIVED KEY CERT HASH
1.3.6.1.4.1.311.21.17 szOID_ISSUED_CERT_HASH OID ISSUED CERT HASH
1.3.6.1.4.1.311.21.19 szOID_DS_EMAIL_REPLICATION OID DS EMAIL REPLICATION
1.3.6.1.4.1.311.21.20 szOID_REQUEST_CLIENT_INFO OID REQUEST CLIENT INFO
1.3.6.1.4.1.311.21.21 szOID_ENCRYPTED_KEY_HASH OID ENCRYPTED KEY HASH
1.3.6.1.4.1.311.21.22 szOID_CERTSRV_CROSSCA_VERSION OID CERTSRV CROSSCA VERSION
1.3.6.1.4.1.311.25 Microsoft_Directory_Service Microsoft Directory Service
1.3.6.1.4.1.311.25.1 szOID_NTDS_REPLICATION OID NTDS REPLICATION
1.3.6.1.4.1.311.30 IIS IIS
1.3.6.1.4.1.311.30.1 szOID_IIS_VIRTUAL_SERVER OID IIS VIRTUAL SERVER
1.3.6.1.4.1.311.43 Microsoft_WWOps_BizExt Microsoft WWOps BizExt
1.3.6.1.4.1.311.44 Microsoft_Peer_Networking Microsoft Peer Networking
1.3.6.1.4.1.311.44.1 szOID_PEERNET_PNRP OID PEERNET PNRP
1.3.6.1.4.1.311.44.2 szOID_PEERNET_IDENTITY OID PEERNET IDENTITY
1.3.6.1.4.1.311.44.3 szOID_PEERNET_GROUPING OID PEERNET GROUPING
1.3.6.1.4.1.311.44.0.1 szOID_PEERNET_CERT_TYPE OID PEERNET CERT TYPE
1.3.6.1.4.1.311.44.0.2 szOID_PEERNET_PEERNAME OID PEERNET PEERNAME
1.3.6.1.4.1.311.44.0.3 szOID_PEERNET_CLASSIFIER OID PEERNET CLASSIFIER
1.3.6.1.4.1.311.44.0.4 szOID_PEERNET_CERT_VERSION OID PEERNET CERT VERSION
1.3.6.1.4.1.311.44.1.1 szOID_PEERNET_PNRP_ADDRESS OID PEERNET PNRP ADDRESS
1.3.6.1.4.1.311.44.1.2 szOID_PEERNET_PNRP_FLAGS OID PEERNET PNRP FLAGS
1.3.6.1.4.1.311.44.1.3 szOID_PEERNET_PNRP_PAYLOAD OID PEERNET PNRP PAYLOAD
1.3.6.1.4.1.311.44.1.4 szOID_PEERNET_PNRP_ID OID PEERNET PNRP ID
1.3.6.1.4.1.311.44.2.2 szOID_PEERNET_IDENTITY_FLAGS OID PEERNET IDENTITY FLAGS
1.3.6.1.4.1.311.44.3.1 szOID_PEERNET_GROUPING_PEERNAME OID PEERNET GROUPING PEERNAME
1.3.6.1.4.1.311.44.3.2 szOID_PEERNET_GROUPING_FLAGS OID PEERNET GROUPING FLAGS
1.3.6.1.4.1.311.44.3.3 szOID_PEERNET_GROUPING_ROLES OID PEERNET GROUPING ROLES
1.3.6.1.4.1.311.44.3.5 szOID_PEERNET_GROUPING_CLASSIFIERS OID PEERNET GROUPING CLASSIFIERS
1.3.6.1.4.1.311.45 Mobile_Devices_Code_Signing Mobile Devices Code Signing
1.3.6.1.4.1.311.88 CAPICOM CAPICOM
1.3.6.1.4.1.311.88 szOID_CAPICOM OID CAPICOM
1.3.6.1.4.1.311.88.1 szOID_CAPICOM_VERSION OID CAPICOM VERSION
1.3.6.1.4.1.311.88.2 szOID_CAPICOM_ATTRIBUTE OID CAPICOM ATTRIBUTE
1.3.6.1.4.1.311.88.2.1 szOID_CAPICOM_DOCUMENT_NAME OID CAPICOM DOCUMENT NAME
1.3.6.1.4.1.311.88.2.2 szOID_CAPICOM_DOCUMENT_DESCRIPTION OID CAPICOM DOCUMENT DESCRIPTION
1.3.6.1.4.1.311.88.3 szOID_CAPICOM_ENCRYPTED_DATA OID CAPICOM ENCRYPTED DATA
1.3.6.1.4.1.311.88.3.1 szOID_CAPICOM_ENCRYPTED_CONTENT OID CAPICOM ENCRYPTED CONTENT

802.1x TLS authentication with Android, iPhones and iPads

2010-07-19T18:27:00.000+02:00

In my last post I explained how to deploy the necessary infrastructure in order to connect macs to a 802.1x TLS protected network. In that post I´ll explain how to connect an Android or iPhone. The first thing you need is to add the device object in Active Directory and create certificate with the same characteristics as the one for the mac. Make sure you add "host/" at the beginning of the CN field preceding the name of the device as added in Active Directory.

Once you have the PKCS12 containers (.pfx file) with the device certificate, the key and the related certificates chains import it to the device and configure the WLAN interface as follows:

Android 2.1:
For Android, the first think you have to do is enable the credentials store. Go to "Settings", "Location and Security", and set password. Put the PKCS12 file in the root of the SD Card and come back to the security menu. Click on "Install from SD Card" and choose the appropriate file. You´ll be promoted to install the certificate, key and Root CAs. Once installed you can try to connect to the 802.1x TLS protected WLAN. Connect to the 802.1x TLS protected WLAN. As the network will request TLS authentication, the Android would request you to unblock your credentials storage. Enter the password and click Accept. In the configuration screen add the following parameters:
- EAP_ TLS
- No second phase authentication
- Choose the CA certificate (you should have only one)
- Choose the user certificate (you should have only one)
- In the identity entry add the same you added in the CN of the certificate. It should be something like: "host/machine-name"

I have successfully tested it with Android 2.1. The draw back is that you most probably will require a proxy to access the Internet and that can´t be configured in Android (unless you use a Cyanogen build)

iPhone 3, iPhone 4 and iPad:
Send the PKCS12 file by email and open it from the mail application. Follow the same instructions as the ones to connect an Android device to the WLAN. Remember to manually add the CN as the Identity with the "host/" at the beginning.

802.1x TLS authentication with Macintosh

2010-07-16T18:05:00.002+02:00

At the company where I´m working we have a nicely integrated CA with our Active Directory that allows us to automatically provision our PCs with a client certificate assigned to the System account, mostly known as a machine certificates. We are using these certificates for authenticating the devices before granting them access to the network using 802.1x EAP-TLS. We chose that solution to ensure that only corporate computers would connect to the trusted network, redirecting the rest to a semi protected network with access to the Internet and little more.

As any other enterprise we have been silently invaded by macs and now we have to find a solution to connect them to the trusted network, which in our case, implies delivering a machine certificate.

I`ll skip you the troubleshooting and go directly to the solution.
Building blocks:
- Windows 2008 Microsoft Enterprise CA
- IAS Server (Microsoft RADIUS)
- MacBook Pro, Mac OS X Snow Leopard
- WinXP SP3

I'm assuming that you have a Microsoft Integrated CA and that the 802.1x TLS is already working for the PCs. For Standalone CA (and probably non IAS Server), you might find that link useful https://airheads.arubanetworks.com/vBulletin/archive/index.php/t-1437.html

1) First you need to create a dedicated Certificate Template for issuing the certificates to the macs. The fastest solution is to duplicate the template you are using for delivering the current machine certificate but with the following changes:

- Change the Subject Name to "Supply in the request":

- Make sure you mark the check box "CA certificate manager approval". That is not strictly necessary but without this you might have severe security problems. It´s also recommended that you limit the users allowed to upload the requests.

- When you are using PCs and Autoenrollment most probably you are not allowing users to export the certificate private key. In our company we have decided that a dedicated group in IT Support will generate the certificates in a windows box, export and transfer them to a mac. In order to do so we have to check the "Allow private key to be exported":

- Once you have that in place you can craft a Certificate Signing Request and upload it to the CA. For creating the proper CSR you should know the mac name as provisioned in the Active Directory. We use the Microsoft tool LCSCertUtil. If you too, make sure you uncheck "Disable Template" and check "Exportable Private Key".

It´s very important you add the proper CN and SAN fields. If you machine name is X1234.companydomain.com make sure your CN is host/X1234.companydomain.com and the SAN is X1234.companydomain.com. That is the only difference between the machine certificates delivered to windows boxes and the rest.

- Once you have the certificate in the Windows box, open Internet Explorer go to Tools, Internet Explorer, Content, Certificates; choose the certificate and export it in a PKCS12 container (windows will generate a .pfx file) making sure you include the private key and the certificate chains.

- The next would be to import the file in the mac keystore and create a 802.1x profile in the mac assigning the certificate in the TLS protocol using the Advanced network features (make sure you disable the other protocols), but if you reached that point it should not be a big deal.

Good night and good luck.

Verify Server certificate

2010-05-20T00:36:00.002+02:00

As the first real post I want to start with the basics. As a manager of a trusted CA the most common complain I receive is that the certificate "does not work". In 99% of the cases the root of the problem is that the administrator did not install the proper SubCA or SubCAs or it install them in the wrong CA store (if the server is a IIS).

I always provide the following possibilities in orded to verify the SubCAs sent by the server.

* openssl (http://www.openssl.org/) If you can have acess to it just run:

openssl s_client -connect SERVERNAME:443 

where SERVERNAME is the DNS name of the server you want to verify. Run the command and check the "Certificate chain" part. In most cases you´ll need to see the certifcates 0 (the server certificate) and 1 (the chain). There are cases you might even need an extra chain. It´s necessary that the Issuer (i:) of the last certificate is available on the client, otherwise you´ll have an error.

openssl s_client -connect google.com:443
CONNECTED(00000003)
depth=1 /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
   i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDITCCAoqgAwIBAgIQL9+89q6RUm0PmqPfQDQ+mjANBgkqhkiG9w0BAQUFADBM
MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg
THRkLjEWMBQGA1UEAxMNVGhhd3RlIFNHQyBDQTAeFw0wOTEyMTgwMDAwMDBaFw0x
MTEyMTgyMzU5NTlaMGgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh
MRYwFAYDVQQHFA1Nb3VudGFpbiBWaWV3MRMwEQYDVQQKFApHb29nbGUgSW5jMRcw
FQYDVQQDFA53d3cuZ29vZ2xlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEA6PmGD5D6htffvXImttdEAoN4c9kCKO+IRTn7EOh8rqk41XXGOOsKFQebg+jN
gtXj9xVoRaELGYW84u+E593y17iYwqG7tcFR39SDAqc9BkJb4SLD3muFXxzW2k6L
05vuuWciKh0R73mkszeK9P4Y/bz5RiNQl/Os/CRGK1w7t0UCAwEAAaOB5zCB5DAM
BgNVHRMBAf8EAjAAMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwudGhhd3Rl
LmNvbS9UaGF3dGVTR0NDQS5jcmwwKAYDVR0lBCEwHwYIKwYBBQUHAwEGCCsGAQUF
BwMCBglghkgBhvhCBAEwcgYIKwYBBQUHAQEEZjBkMCIGCCsGAQUFBzABhhZodHRw
Oi8vb2NzcC50aGF3dGUuY29tMD4GCCsGAQUFBzAChjJodHRwOi8vd3d3LnRoYXd0
ZS5jb20vcmVwb3NpdG9yeS9UaGF3dGVfU0dDX0NBLmNydDANBgkqhkiG9w0BAQUF
AAOBgQCfQ89bxFApsb/isJr/aiEdLRLDLE5a+RLizrmCUi3nHX4adpaQedEkUjh5
u2ONgJd8IyAPkU0Wueru9G2Jysa9zCRo1kNbzipYvzwY4OA8Ys+WAi0oR1A04Se6
z5nRUP8pJcA2NhUzUnC+MY+f6H/nEQyNv4SgQhqAibAxWEEHXw==
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
issuer=/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
---
No client certificate CA names sent
---
SSL handshake has read 1765 bytes and written 313 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol : TLSv1
    Cipher    : RC4-SHA
    Session-ID: B3E695F8FA99A262EC5916678E686907ABF5CC2EE5B85EE994A3CBE7360B0DBA
    Session-ID-ctx:
    Master-Key: FFA4CB2368CDAF125D1284CC0CA739C0A40E9E429B5CD07FAF7177546694D7448524242B513749CFE33C14DE0D129746
    Key-Arg   : None
    Start Time: 1274307867
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

* Online Tool. If you can't use openssl or you are afraid of using the command line there are plenty of online tools that will check the certificate for you. Find below a couple of links that work quite well:

http://jce.iaik.tugraz.at/sic/Products/Communication-Messaging-Security/iSaSiLk/demo
Although the page is in German, it´s quite simple to use. What I like is that it provides all information oyu need and more.

http://www.sslshopper.com/ssl-checker.html
Nice format and simpler to read but with less information.

Here we are!

2010-05-19T20:48:00.003+02:00

After several years crawling the Internet looking for pki related questions I think is time I feedback my own solutions. The idea is to post my finding on Code Signing, TLS, Document Signing, encryption and similar.
I hope you find it useful.