View Issue Details

IDProjectCategoryView StatusLast Update
0000014Main CAcert Websiteweb of trustpublic2013-01-13 13:39
Reporterhomer Assigned To 
Status closedResolutionfixed 
Fixed in Version2006 
Summary0000014: 0000019: Tverify does not work in some cases : wrong thawte cert verification assumptions ?
DescriptionThe verification process of the tverify page is toooo simple.

It assumes that the ?Common Name-attribute (CN) of a Twathe Certificate is build like this: Firstname [space] Lastname

While this will work in simple cases like:
John Smith

It will not work for people with multiple firstnames and/or Lastnames with verbs in them.

Just look at this real-life (changed the names to protect the innocent) case, as taken from Firefox:
E =
CN = James Martin Luther van de Poort
Objectidentificatie (2 5 4 42 ) = James Martin Luther
Objectidentificatie (2 5 4 4 ) = van de Poort
In IE the last to are called: G and SN (most likely meaning Givename and ?Sur Name).

The code to verify the full-name however is flawed IMHO. It assumes (assumptions are always deadly) that the first space is the seperation between first and last name. I understand why this is done, you want to be able to lookup the data in the database. And that depends on the setup of the database tables.

An easy fix seems no to use the CN value of the certificate, but the other two object types, called G and SN (=surname). At least the SN part is X.500 compliant and should be located in each Certificate issues by Twathe. The G is the Givename I think, so that should match what you enter the firstname concept. So without splitting the CN (Common Name) in two object, you should be able to improve the code so that it matches when you have entered it the same in CACert and Twathe.

Next should be the assumption on middlename and the usecases that the order of names is different (for what ever reason).

Also, it would be great to have a little more error information for the user trying this. So displaying the found firstname, lastname, commonname and e-mail from the certificate. And if there is a matching account in the database. Would be great info, when the come to the support maillist.

I have posted my finding on the support list was well, just look in the archives.
BTW. The Middlename convention as used in CAcert, is NOT used in the Twathe system at all!
Additional Information Giuseppe De Francesco wrote:

> Hi,
> I've tried, but the php code still confuse the Thawte cert. (see attached) My CN="Giuseppe De Francesco", where G="Giuseppe" and SN = "De Francesco", so the Thawte Cert is correct. Is the CaCert page that splits only the CN on spaces, so it will be *impossible* to match the Thawte cert. This (I think) is not just an improvement of the CaCert web site, but a *must*, because the CN field is for descriptive purposes, while G and SN are the field that *shall* be analized to check separately Given name and SurName. What happens if Mr. "Giovanni Frascati Della Loggia" will use a Thawte cert with CaCert??? CN="Giovanni Frascati Della Loggia", G="Giovanni", SN="Frascati Della Loggia" !!! Split the CN to get G and SN is just an error that must be fixed.
> Cheers
> Pino

I would tend to agree that its a very dumb idea to try to parse the CN rather than looking at the G an SN entries. Of course CAcert is full of inconsistancies like this.
TagsNo tags attached.
Attached Files
0.patch (1,363 bytes)   
< 		// get the equivelent content from the database
< 		$query = "select `fname`, `mname`, `lname`, `suffix` from `users` where `id`='$memid' and `deleted`=0";
< 		$res = mysql_query($query);
< 		$row = mysql_fetch_assoc($res);
< 		$cacert_name_parts = array( $row['fname'], $row['mname'], $row['lname'], $row['suffix'] );
< 		$cacert_name = implode( " ", $cacert_name_parts );
< 		// replace punctuation
< 		$cacert_name = strtr( $cacert_name, ",.", "  " );
< 		// replace all double spaces - in case ", " was changed to "  ", for example
< 		while(strstr($cacert_name, "  "))
< 			$cacert_name = str_replace("  ", " ", $cacert_name);
< 		// now do the trim - this was moved in case of a period in the suffix, for example
< 		$cacert_name = trim( $cacert_name );
< 		$cacert_bits = explode( " ", $cacert_name );
> 		$firstname = $bits["0"];
> 		$lastname = $bits[count($bits) - 1];
< 		if (count($bits) != count($cacert_bits))
> 		$query = "select * from `users` where `fname`='$firstname' and `lname`='$lastname' and `id`='$memid'";
> 		if(mysql_num_rows(mysql_query($query)) <= 0)
< 		} else {
< 			for( $i = 0 ; $continue == 1 && $i < count($bits)  ; $i++ )
< 			{
< 				if ( $bits[$i] != $cacert_bits[$i] )
< 				{
< 					$continue = 0;
< 				}
< 			}
< 		}
< 		if ( $continue != 1 )
< 		{
0.patch (1,363 bytes)   
Reviewed by
Test Instructions


related to 0000438 closed tverify fails if optional middle name doesn't match 



2005-09-07 02:46

reporter   ~0000006

When I look at tverify :

$name = trim($_SERVER["SSL_CLIENT_S_DN_CN"]);
while(strstr($name, " "))
    $name = str_replace(" ", " ", $name);
$bits = explode(" ", $name);
$firstname = $bits["0"];
$lastname = $bits[count($bits) - 1];

$query = "select * from `users` where `fname`='$firstname' and
`lname`='$lastname' and `id`='$memid'";

As far as I read

if the Thawte cert mentions : "Giuseppe De Francesco"
first name is "Giuseppe"
lastname is "Francesco"

so it will never match a user

first name "Giuseppe"
last name "De Francesco"

right ?

Are we skeptical with the old european nobility ? (LOL, I know people
from Australia do not like much their Queen !)

I would be also in trouble if I had my ancestor's name "De ROMAGNE" !

I would propose to match the "last last" name and send it to the
cacert-verify list

Else Francesco have the option to use "De" has his second name but I
guess it is no good.


2006-06-01 23:03

reporter   ~0000243

OIDs and are indeed the attributes for GivenName and Surname respectively. GivenName as a synonym for First Name, also referred to in the west rather arrogantly as Christian Name. Surname is a synonym for Last Name. In the strictest interpretation, there is no place for Middle Name, or Suffix (Jr., Sr., III, etc.) in these fields, but it is a common practice in LDAP stores to use these fields to include the values so the Common Name (CN, OID can be constructed by combigning the G and SN fields.

If you want Thawte certs to be used this way, you'll have to modify your side, since once a person is Notarized (geven any points) in the Thawte system, it is not possible to change the name fields except for legal reasons like marriage which require non-trivial interraction between humans.

It would take some work, and if I can find the source code and learn the language (I'm a Java/C++ freak, never really got into the P-languages) I'll try to put a patch together to to:

- Parse the G and SN in order into individual fields using whitespace as separators, treating punctuation as whitespace - treat the fields as a queue.
- For each field out of the CACert database (First, Middle, Last, Suffix), parse the same way, popping fields off the queue and matching fields in order.

- If underflow does not occur, and the queue has exactly zero items left upon completion, this is a valid match.


2006-06-02 14:09

reporter   ~0000246

I'm no PHP guru and I don't have a way to test the code at the moment, but it was a relatively straght forward task to do what I think is a much more complete check. This code should work fine for the two test cases documented, as well as for something like Pelentje Burs van der Poot, III (I found that name on the internet) where fname = Pelentje, mname = Burs, lname = van der Poot, and suffix = III.


2006-08-08 05:55

developer   ~0000332

Not entirely sure what the patch was trying to achive, however I added the following lines to tverify/index/0.php

                $firstname = trim($_SERVER["SSL_CLIENT_S_DN_G"]);
                $lastname = trim($_SERVER["SSL_CLIENT_S_DN_S"])

                $query = "select * from `users` where `fname`='$firstname' and `lname`='$lastname' and `id`='$memid'";

And this should hopefully ignore any/all suffixes or prefixes.


2006-08-14 08:47

administrator   ~0000444

This is just a test (because of Internet outages we currently have). Please ignore it.


2007-05-19 20:03

administrator   ~0000845

I have integrated more of the patch into TVerify now, but adapted it to have a cleaner structure. It has been tested successfully, the code is in the tarball now. We will open a new feature request for better handling middle names at tverify soon.

Issue History

Date Modified Username Field Change
2005-09-06 18:22 homer New Issue
2005-09-07 02:46 homer Note Added: 0000006
2005-09-14 06:30 homer Reproducibility always => sometimes
2005-09-14 06:30 homer Summary 0000019: Thawte verification assumptions => 0000019: Tverify does not work in some cases : wrong thawte cert verification assumptions ?
2006-06-01 23:03 blackard Note Added: 0000243
2006-06-02 14:03 blackard File Added: 0.patch
2006-06-02 14:09 blackard Note Added: 0000246
2006-08-08 05:55 duane Status new => solved?
2006-08-08 05:55 duane Fixed in Version => production
2006-08-08 05:55 duane Resolution open => fixed
2006-08-08 05:55 duane Assigned To => duane
2006-08-08 05:55 duane Note Added: 0000332
2006-08-14 06:01 duane Status solved? => needs work
2006-08-14 06:01 duane Assigned To duane => homer
2006-08-14 06:02 duane Status needs work => solved?
2006-08-14 08:47 Sourcerer Note Added: 0000444
2007-05-19 20:03 Sourcerer Note Added: 0000845
2007-05-19 20:45 homer Relationship added related to 0000438
2007-10-24 05:51 evaldo Status solved? => closed
2013-01-13 13:39 Werner Dworak Assigned To homer =>
2013-01-13 13:39 Werner Dworak Fixed in Version => 2006