Hidden Security Login in Certificate

You don't have the root certificate chain installed.
Open up the certificate again and look on the details tab for the Authority Info Access field and select it - there will be a URL in the text box underneath that you can use to get the issuing CA's certificate - if that is not the root, you can do the same to that certificate and so on until it is the root certificate (where subject and issuer are the same on the details tab).  If you want to trust that root certificate you can, and that would get rid of the error.  It might help in some cases to install each CA's certificate, but typically just the root cert is fine.

Sounds like it is trying to do client certificate authentication...

(assuming you have a certificate that is supposed to be valid for that site here - if not, you probably aren't authorized to go there)

A llittle closer look - looks like a normal Run As box - shift+rightclick - Run As... in the username the funny green thing is a certificate.  This could be a certificate file either on your hard drive or on a smart card / smart usb token.  The certificate would be issued to one of the users on your computer - you could ask them.  Basically instead of supplying a username and password you supply the certificate to log in - the certificate may have its own PIN but that isn't transmitted across the network like a password is.

It is likely not anything to worry about and might even be a good thing.

We knew this problem came in through e-mail disguised as a zip. The issue was how do you prevent and detect such certificates, Note: the user has user privileges and should have been able to install.
We know this e-mail was a virus or Malware. It was only by chance on the same day the technician actually discovered. Antivirus software did not flag it, and looking for such a certificates on a mass scale is time consuming and expensive.

******  Point to the person who can tell us how to automate a search for this type of certificate.

Script??

This is a touchy one.  Normally you want certificates to pass through when they are from a trusted source - i.e. you already have the root CA cert approved (either your own, built into windows, or a partner company). However, there is a level of risk inherent to the system, which is where the process of trusting a root certificate comes into play.  You trust the root, you trust that whomever is in charge of that root follows certain practices to prevent misuse and abuse (in a proper PKI, these would be documented in a Certificate Policy and a Certificate Practice Statement - CP and CPS, and preferably independently audited against their CP & CPS).  Once you trust the root, every cert under that root is trusted.  The same will go for a 'self-signed' certificate - one that a server can generate for itself when an admin doesn't have their own CA and doesn't want to pay a public commercial CA for a properly recognized cert.

The problem comes in when you trust something you shouldn't.  This opens the door for you and your users to have a false sense of trust in a site's security and validity.  Commercial CA's don't just issue a cert to anyone that gives them a few bucks, they need to verify that the company actually exists and that the person requesting is authorized, at minimum.  If you get an email with a certificate that you were not expecting, you should not install it.  Installing it would make phishing sites that much more beleivable.  The traffic will still be secured with SSL, but there's no guarantee what will happen when it gets there!

Because of this, email servers (e.g. Exchange) will typically filter out certificate files (.cer, .crt, .pfx, .p12, .p7b, .p7c, etc.), so users quickly adapt and zip them up and send them that way to circumvent that process.  You would need to have a program examine your zip files - if they are encrypted or password protected zip files maybe they can be held for manual inspection or just deleted.  I'm sure there are plenty of programs for doing this - not my area of expertise to recommend a good product to do this.

This certificate has already expired, so removing it is technically not necessary, however if you really want to you can do so using certmgr.msc (Certificates MMC) locating it and deleting it (start from the top down - take note when you find it, and continue looking in case it ended up in more than one area).  Note that you might want to export it first (particularily one like in the picture that says you have the private key) just in case it ends up being something that you find later that you actually needed and just misunderstood the process how it got there.

Since it has the warning message that it could not verify it, it appears that it was not installed to the root certificate store.  Once you find the correct store(s) then you can take care of any additional machines via script:
certutil -delstore [CertStoreName] [cert token name]

The CertStorename will probably be "My" (no quotes) as I am guessing it ended up in Personal, otherwise just post where it ended up and I can be more specific.  If memory serves the serial number or thumbprint of the cert will work fine for the cert token name field - you can get that from the Details tab of the cert.

I'm just checking in on old posts today... Are you still having this issue?  If so, please let me know so I can help some more, if not, please close accordingly..

The issue was how do you prevent (silent install) of certs. oh It ended up in Personal and some donot expire for years.  The security impact is not Clear.

To Date, The problem is still out thier and is found by manually checking.    Poiicy has not been define on this.  

Not enough information to make it main stream I guess.