Re: Untrusted certificates with Friendly Name of "Fraudlent, NOT Microsoft"?

From: Eduard Koller [MSFT] (eduardk_at_online.microsoft.com)
Date: 05/18/04 

Date: Tue, 18 May 2004 10:53:38 -0700

The certificates *are* revoked. (they got revoked shortly after they have
been issued)
In the meanwhile, they also expired, and this is why you see "expired".
If the cert is expired, it doesn't really matter if it was also revoked or
not. It is not valid anyway. 

-- 
Eddy Koller[MS]
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at 
http://www.microsoft.com/info/cpyright.htm
"*Vanguard*" <no-email@reply-to-newsgroup.invalid> wrote in message 
news:VP-dneoSA-ZssTndRVn-vg@comcast.com...
> Alun Jones [MS MVP - Security] said in
> news:agPoc.26857$OV5.12690@newssvr22.news.prodigy.com:
>> In article <7pOdnQZBsooYNj_d4p2dnA@comcast.com>, "*Vanguard*"
>> <lh_811news@yahoo.invalid> wrote:
>>> According the article, some a-hole pretended to be Microsoft and got
>>> a couple certs purporting to be for Microsoft.  But then why would
>>> this potential hacker put "Fraudulent, NOT Microsoft" right in the
>>> *optional* Friendly Name field?
>>
>> The hacker didn't.  Microsoft did, when they included them in an IE
>> service pack as untrusted certificates.  Go ahead - edit the friendly
>> name on those certificates - note how you can do so, indicating that
>> this is not one of the fields that is in the certificate itself.
>> It's a bit like the difference between a file name and the file's
>> contents.  You can change the file's name without changing the file's
>> contents.
>
> I know the Friendly Name field is editable.  When I created an
> EFS-protected folder, I got a new certificate.  Although the Intended
> Purposes field shows it was for, I wanted some additional info so I put
> it into the Friendly Name field.  Rather than have to open all my
> certificates to see what each is for, I edit the Friendly Name field.  I
> find it helpful when I have many Thawte freemail certs.  The Intended
> Purposes field says <All> in certmgr.msc.  I'd rather easily see for
> which e-mail address each was for, so I put that in the Friendly Name
> field.  Then I can easily see which Thawte cert is for which e-mail
> address without having to open the properties of the cert and look under
> the Details tab to scroll down to the Subject attribute to find out
> using that longer method.
>
> What you are saying is the the security update modified this field to
> help identify the bogus certs.  Their content is what started this whole
> discussion so I guess it worked but it's not an obvious trigger for most
> users because, as you say, it is an editable field.  I was expecting
> their status to get set to "revoked" rather than just expiring them to
> get them moved into the Untrusted Certificates group.
>
> Also, the value "Fraudulent, NOT Microsoft" really doesn't tell me that
> it was Microsoft or one of their updates that entered that value.
> Would've been much better to clearly identify their action with
> something like "Fraudulent, see Microsoft KB article 293818".
>
> I initially also expected the security update to actually delete the
> bogus certificates.  However, maybe they were left there deliberately to
> prevent possibility of getting them downloaded again later to inflict
> harm after the security update had been applied.  That is, they were
> retained because being untrusted means their use will trigger some
> warning to user as opposed to if they had been deleted then getting a
> dialog to accept them which the user might do so they then become
> trusted certs.
>
> So, at this point, I'm not sure if I should delete those expired (and
> supposedly revoked) certificates or if I should leave them there to
> prevent an accidental install sometime after the security update (which
> would then obviate the security update).
>
>>> Also, why doesn't Microsoft list the serial numbers for these
>>> fraudulent certificates?  The article says, "Installs a CRL onto the
>>> local machine. The CRL lists the two bogus certificates as having
>>> been revoked."  The certs aren't revoked.  They have expired.  Also,
>>> this is a fresh install of Windows and all applications since about
>>> Tuesday, and Windows Update has been ran repeatedly until no further
>>> uploads were listed (except for the driver uploads which I *never*
>>> touch).  According to Windows Update (the web page, plus I have its
>>> local client running automatically on startup), there are no more
>>> updates to get.  The article shows this problem is old and dates
>>> back to March 2001.  I also have all the latest available Office
>>> updates.
>>
>> CRLs aren't checked by all applications.  By installing these two
>> certs in the Untrusted Certificates store, both bases are covered.
>
> The security update actually *installs* the bogus (and expired) certs?
> If so then I really should NOT delete them.
>
>> The certificates have expired, because they were purchased a long
>> time ago, and Verisign did not renew the certificates.  But what do
>> you do when you get a message that says "this certificate is valid,
>> but has expired"?  Do you think all users will say "oh, well, better
>> stop trusting it, then", or do you think some will say "oh, they just
>> forgot to renew it, I've seen that happen before", and will accept
>> the bogus certificate?
>
> Actually that DOES happen.  For example, I think it was an install of
> some Symantec software that adds a certificate but it is already
> expired.  The expired cert is still required to authenticate the
> Symantec product.  I think a subsequent update gets rid of the expired
> ones and installs new ones.  So, yeah, you will momentarily have expired
> certificates but they are mandatory.  You don't get rid of them nor do
> you stop using them just because they are expired.  Revoked means they
> are definitely bad.  Expired just means you haven't gotten a new one
> from them yet (and you may never get a new one since obviously you have
> no means of physically enforcing, say, an e-mail sender to get a new
> digital ID cert).
>
> There is no difference between a revoked certificate and an expired one?
> Revoked certs just get expired and moved under Untrusted Certificates?
> When a certificate is found to have been revoked, just what happens to
> that certificate on the client host that has it?  I doubt it would get
> deleted.  Expiring a cert or using an already expired one seems
> inappropriate.  If it is revoked, shouldn't the status for it say
> revoked?
>
>>> I ran the crlupd.exe update but nothing changed.  The two certs were
>>> still listed under Untrusted Certificates and showed as expired
>>> instead of revoked.  But then I've never before had a revoked
>>> certificate so maybe that is how they get revoked.  I was expecting
>>> some big marquee blaring "REVOKED" or some such clear identification
>>> that the certificate got revoked rather than just expired.
>>> Expiration just means it is old and all certificates expire.
>>
>> Revocation is handled elsewhere - by the code that checks the
>> certificate chain.  Also, why would the list of Untrusted
>> Certificates even _bother_ to check if the untrusted certificates
>> were also revoked?  It's a bit like saying that a person who was
>> deported for lying on his immigration form should also be deported
>> for having a criminal record.
>
> All I can tell of the untrusted certificates is that their term of
> validation has expired.  To me, that is not the same as revoked.  That's
> like saying everyone accused of a crime is guilty, or that just because
> it is past the expiration date printed on the milk carton means it has
> become deadly poison.  I don't see expiration as equating to revocation.
> The status of the certificates found under the Untrusted Certificates
> category was "This certificate has expired or is not yet valid".  Is
> there no means of specifically setting the status to "Revoked" rather
> than assuming every certificate that has expired has been previously
> revoked.  Revoked takes action to do so.  Expiration is completely
> passive and infers nothing necessarily super evil about the certificate.
>
>>> Is there someplace at Verisign (the issuer) to check who owns the
>>> certificate based on its serial number?  After 20 minutes, my eyes
>>> glazed over trying to find where to download their latest CRL.  I
>>> found crl.verisign.com but don't know which to download for the
>>> questionable certificates.  It's not like you can right-click on a
>>> certificate and perform a revoke check (by downloading the latest
>>> CRL from wherever the CA has it stored).
>>
>> After they issued a certificate to "Microsoft" and handed it to the
>> wrong person, you're going to ask them to look up "who" owns another
>> certificate?
>
> I don't get your point.  All certificates are supposed to identify to
> whom they were assigned.  That is NOT supposed to be a secret.  That's
> why you use certificates - to identify who you are!  Why hide the
> information via a lookup from the CA for the same information that is
> already included within the certificate itself?  Are you claiming that
> there is absolutely no means to generate fake certificates?  You've
> never heard of a cop knocking on someone's door, presenting a badge to
> supposedly prove who they are, but the occupant still insists on calling
> the police to confirm the person at the door is actually one of their
> officers?  Also, until the user actually gets a new CRL, they won't know
> the certificate has already been revoked.
>
> What I'm asking is to do the same thing that OCVS (Online Certification
> Verification System) will do and which replaces using static copies of
> CRLs.  CRLs are like store clerks getting bad check lists from banks and
> then having to scan them to determine if a check is bad.  Static local
> copies of lists are only useful depending on how often they get updated.
> Instead OCVS queries the CA if the certificate is still good and that
> verification is immediate and timely.  That is the same thing that I'd
> like to do when *I* am reviewing the certificates on my system.  I'd
> like to go check the status of a certificate right NOW when I'm looking
> at it.  I see nothing in Certificate Manager (certmgr.msc) to force the
> download of the most recently updated CRL so that *I* know they are okay
> at that immediate moment that I'm looking at them.
>
> RedHat - Verify a Certificate:
> http://www.redhat.com/training/certification/verify/
>
> Apparently Netscape permits users to on-demand verify a certificate:
> https://rmb.ogden.disa.mil/digcerts_verify.htm
>
> Verisign - Lookup by e-mail address:
> https://digitalid.verisign.com/services/client/index.html
> But I want to lookup by serial number or MD5 hash code (can't get it to
> work for this web page).  And this only looks up for digital IDs.  Never
> did find this when hunting through their web pages.  Found it through a
> Google search.  Interestingly, note what gets returned if you enter
> "support@microsoft.com" on an e-mail search.
>
> Also found at Verisign:
> https://securitycenter.verisign.com/celp/enroll/outsideSearch?application_locale=VRSN_US&originator=VeriSign:CELP
> When I try to enter a serial number even for one of Verising's own certs
> in my repository, it returns with "illegal characters".  So then I try
> again by removing all the spaces from the copied serial number from the
> properties page for that cert.  Nope, didn't work.  Why make it so damn
> hard for users the verify a certificate?
>
>> As you can tell, the tools aren't exactly written for what you want
>> to do. Perhaps there are shareware tools to do something like this,
>> but I suspect for those particular certificates, you won't find
>> anything of much help.
>
> So far, I've been hunting around the CA's web sites trying to see if
> they provide searches on their own certs.  It's been difficult.  I found
> a couple search pages at Verisign but have yet to get them to accept the
> serial numbers shown in the certificate even after removing the spaces
> between the hex digits.  I had expected the lookups to be easy.  Boy,
> was I wrong.  I'll dig around the CA sites some more and then start
> hunting around for 3rd party software to do the same.
>
>> They're very old, and fairly well known, and
>> their presence in that Untrusted Certificates folder should indicate
>> that they won't be trusted.
>
> My original intention was to get info on them and then delete them if
> indeed they were bogus certificates.  Or, alternatively, if I should
> always be deleting any untrusted certificates, including those that
> expire.  However, it now seems that maybe I am supposed to keep those
> bogus certs in the Untrusted group to ensure they remain untrusted
> should I get any programs that use those bogus code-signing certs.
>
> Might be an old problem but this is a fresh install of Windows XP only
> two weeks old, so I'm still working on tweaking it and investigating
> everything.  I actually only hit this because a restore of EFS-protected
> files had failed (yes, I had the exported certs but they didn't work)
> and started looking around to see what was the problem.  That led me to
> certmgr.msc and as a consequence the untrusted certs were noticed.
>
> Thanks for the help.
>
> -- 
> ____________________________________________________________
> *** Post replies to newsgroup.  Share with others.
> *** Email: domain = ".com" and append "=NEWS=" to Subject.
> ____________________________________________________________
>
>

Relevant Pages