Forgot your password?
typodupeerror
Security The Internet IT

SSL Cert Weaknesses Exposed By Comodo Breach 194

Posted by timothy
from the well-he-showed-me-his-badge dept.
snydeq writes "InfoWorld's Woody Leonhard delves deeper into the Comodo SSL scandal and finds the breach calls into question the integrity of the SSL certification process itself. 'While the press has focused on the sensational fact that Comodo's site was hacked from an Iranian IP address, we really should be asking three questions: How did somebody working with an Iranian IP address get a username and password from Comodo with enough clearance to create SSL certificates? Why did Comodo issue SSL certificates for google.com, live.com, yahoo.com, mozilla.org, and skype.com? Why are browser updates used to revoke SSL certificates?'"
This discussion has been archived. No new comments can be posted.

SSL Cert Weaknesses Exposed By Comodo Breach

Comments Filter:
  • Before those questions are answered, I'd just like to thank Comodo for making my next SSL certification renewal an even easier decision.
    • Re:Thanks Comodo (Score:5, Informative)

      by thue (121682) on Friday March 25, 2011 @08:01AM (#35609796) Homepage

      The beauty of it is that even if you do not buy your certificate from Comodo, you are still just as vulnerable to false certificates in your name from Comodo (Or any other of the ~650 CAs [eff.org]).

      • Question #4, on the list, perhaps.

        Why, if Google's certs come from Thawte, is it that big a problem of Comodo issues a bogus google.com cert?

        Browsers should remember that Google's certs last came from Thawte (a particular root cert) and today, all of a sudden, it is being verified by another company. Browsers should warm you about this. I know a lot of people would just click "yes" and be done with it, but I think also given it would happen worldwide (in the case of a worldwide attack) would bring the story

        • by thue (121682)

          But how do you know whether google is being impersonated, or if they has really switched to Comodo? You can't as far as I can tell.

      • by sjames (1099)

        It's a bit hard to trust the trust system in SSL. Everyone should take a look at the authorities in their browser (preferences,advanced.view certificates,authorities in firefox). I have no idea who most of those entities are and yet I am to trust that they won't screw up and issue a cert for google.com (even under orders from an unfriendly government).

  • by billyswong (1858858) on Friday March 25, 2011 @06:42AM (#35609446)

    If you went to a site with a cert signed by those big companies, those sites are trusted with no questions. If a site don't want to pay and use a self-signed cert instead? Wow, the end-user are warned as if it is more dangerous than plain HTTP site!

    A more rational mechanism should be telling users the truth honestly, i.e. "this site's traffic is encrypted and the authority is promised by xxx.com, or if self-signed, self-proclaimed". Those big companies aren't that trustful, they are just lucky enough to gain an early seat into the root cert trust list in the dawn of internet.

    • by arogier (1250960) *
      If only we weren't beholden to decisions made in the 80's and 90's. IPv4, HTTPS we might as well start over. While we're at it hardware AES extensions on more low power processors, should I really have to choose between a VIA Nano and Core i5 if I want decent SSL encoding speed.
    • by TheSunborn (68004)
      The problem with that solution, is that it give no protection against "man in the middle" attack.
      • The problem with that solution, is that it give no protection against "man in the middle" attack.

        Please elaborate, as I have not suggested any changes in the protocol (yet). I am merely asking browsers to present things more accurately, closer to the truth, not "see the little lock then you are safe" stuff. Also not over-reactive to outdated/self-signed cert.

        • by Nursie (632944)

          You would have self-signed certs presented as "semi-secure", which they are not.

          • by sjames (1099) on Friday March 25, 2011 @03:05PM (#35615054) Homepage

            Not at all. The current state of affairs is that self-signed certs are treated almost as bad as invalid certs. The site's identity with a self-signed cert is just as good as an unencrypted connection would be (but no better) but it is more secure against 3rd party sniffing. I would rather it look the same as an unencrypted connection (no lock icon, no green trust indicator) rather than the OMFG IT'S A SELF-SIGNED CERT!!!!!!!!! click here, here, here, and here, gee, it was nice knowing you! like it does now. Perhaps it should display a 'cone of silence' icon.

            However, if the cert has changed since the last time I visited a site, especially if it's now signed by a different authority, I should be concerned MORE than a self signed cert, especially if the previous cert shouldn't be near expiring yet.

            The problem is that trust is fine grained and multi-dimensional but is presented as a simple go/no-go threshold.

        • by TheSunborn (68004)
          The problem is that anyone can create a self signed cert to your site.

          Imagine that you use a self signed certificate on yourdomain.com

          When a user then connect the first time and is presented with the cert, that user have no way to know if the cert he see is greated by you, or created by someone claiming to be you.

          Remember: Anyone can create a self signed certificate to google.com
          • by Confusador (1783468) on Friday March 25, 2011 @08:22AM (#35609918)

            But it's still better than http, because it's not trying to solve the vulnerability you're complaining about. Plain HTTP is vulnerable to MITM and ANY SORT OF EAVESDROPPING. Self signed certs are vulnerable to MITM, and eavesdropping (I believe) if the 3rd party catches all of the key exchange. CA signed certs are vulnerable to neither.

            Claiming that self-signed certs are the same as plain-old-http is as ridiculous as claiming that self-signed certs are secure. They won't protect you against an even mildly determined attacker, but they will stop e.g. the Google van from picking up your email. (Yes, that would have been a problem users could have fixed easily, but do you trust them? More layers of security, when easily implemented, are better.)

            • by mwvdlee (775178)

              Basically, HTTP is vulnerable to absolutely everything, uncertified HTTPS is vulnerable to almost everything.

            • The only way HTTP is vulnerable is if you can sniff the traffic. THe only ways you can sniff the traffic are
              1) Be physically in the middle of the traffic (you have control of a proxy, or a router, between user and server.
              2) Be on the same switch (or hub) as one of the endpoints, and use ARP poisoning to intercept all traffic to one of the endpoints (logically in the middle of traffic).
              3) Have a managed port with a mirror port.

              In the first 2 scenarios-- which are by far and away more likely than a hacker ge

              • You forgot one scenario which is becoming more and more common:
                4) the guy at the table next to yours in a cybercafé

                He has the possibility to passively sniff your traffic, but attempting to change your packets would draw serious attention (because he really has no way of suppressing the original packets from the air, so both the unmodified original and the spoofed packets would end up hitting the Wifi access points, leading to weird errors...)

                • by Nursie (632944)

                  Wifi more secure?

                  I don't think so. Injecting packets is not going to be a lot more tricky.

                  Not to mention you have to trust the wifi operator or anyone else that can gain conteol of the AP/router. Pretty trivial in a lot of places.

      • With unencrypted HTTP, any one who can see the packets can snoop the whole session.

        With SSL/TLS, with a self-signed certificate, the attacker has to be in a position to tamper with the packets. The attacker has to impersonate the server to the client, and potentially the client to the server (depending on the attack). This is a much harder problem than simply sniffing the traffic with tcpdump.

        Anyone on a public WiFi network can sniff the packets of other users on the WiFi network. It would be very diffic

        • by igb (28052)
          It wouldn't be trivial to pull off an attack on a self-signed SSL connection, but it's not hard. On a public wifi system (the scenario you're proposing) it's trivial to fake DNS responses faster than the real responder. The attacker then just presents a different self-signed certificate, using the same DN for the subject and the issuer as the target system. The fingerprint will be different, which may or may not trigger a warning, but the warning will be the same as it was when the self-signed cert was in
        • by asdf7890 (1518587)
          It might be harder right now, as you can't just open up firesheep or similar and have it do the work for you, but as soon as someone releases a proof of concept attack that works via arp poisoning you can bet your last penny that script kiddies all over the world will be running the hack.

          Given there are free certs with proper trust paths available that are accepted by the vast majority of browsers (http://en.wikipedia.org/wiki/Startssl#StartSSL is the only one I know of, but there may be others) there is
          • Cain and abel already works and makes it trivially easy to arp poison, as does ettercap. There are already point-and-click WEP and WPA (dictionary) crackers out there. And regardless, firesheep doesnt screw with SSL cracking, it looks for unencrypted login cookies.

            • by asdf7890 (1518587)

              And regardless, firesheep doesnt screw with SSL cracking, it looks for unencrypted login cookies.

              I was suggesting that someone may write something akin to firesheep that integrated the extra hacks required to attempt to MitM the SSL connection, and if/when that happens your self-signed connections are no safer than plain text ones.

        • With SSL/TLS, with a self-signed certificate, the attacker has to be in a position to tamper with the packets

          No, he just has to be in a position to snoop the traffic and forge replies, and then convince the end user that his certificate is just as valid as the legitimate destination.

          Guess what, if you can see the HTTP traffic, youre probably 90% of the way there.

      • obfuscated http [wikipedia.org](https without certificates) is way more secure against wiretapping than not security at all.

        And even then the current GUI of browser for invalid https certificates is way less usefule than expected. Due to the harsh error it is not a good strategy to hack out comodo yourself, since you get a lot of error messages that are not important.

        https does only garantee there is no man in the middle attack. the CA does not say much more than that. Even a malware ridden site for a company "always trus

      • by DarkOx (621550)

        This is the real source of trouble, failure to identify the bigger threat. Man in the middle attacks are a problem but they are not the more serious risk to defend against.

        In order to execute a MITM attack I need to be able to manipulate your routing, dns, or both. Generally such and attack will be therefore limited to a finite number of people.

        The more common attack is phishing! I can get hundreds of CC numbers etc with a successful phishing scheme. So the real value of SSL is identification. Solid ide

      • by roman_mir (125474) on Friday March 25, 2011 @11:02AM (#35611648) Homepage Journal

        This gets repeated over [slashdot.org] and over again [slashdot.org], and still all the MITM scaremongering carries on, while sensible approach of not displaying visual cues for HTTPS with self signed certs, that they are 'secure', but simply encrypting the connection and proceeding to the site, the same way it's done for HTTP is drowned out in the flood of FUD.

        What browsers should do is display the fingerprint for the certificate near the URL, so it's easy to verify, but rather than that, HTTPS connections should be treated exactly like HTTP connections, unless there is a CA, in which case the browser should provide visual cues that a third party CA believes this is the actual certificate for the site, that the browser connects to.

    • Re: (Score:3, Informative)

      by Rigrig (922033)

      I agree it's stupid how browsers show self-signed certificates as more dangerous than plain HTTP.

      The difference between paid-for certificates and self-signed certificates means more than just who promises authenticity though: The certificate's signature can be checked against the certificate shipped with the browser, thus preventing MITM attacks.

      Basically:

      1. HTTP: everybody on the network can read your stuff, including passwords etc. They don't even need to perform a MITM attack. With a simply MITM attac
    • Re: (Score:2, Insightful)

      by kangsterizer (1698322)

      It is more dangerous when self-signed. Because it gives you a false sense of security otherwise. On plain http you _know_ you are not secure.
      On self-signed you _think_ you are secure so you'll put your credit card number and what not more easily, while in fact, maybe you're not secure.

      Note: self-signed is not necessary unsecure, you just need to make sure you know what you trust when you click "ok and save" the first time.. or get the cert separately and make the same checks.

      • It is more dangerous when self-signed. Because it gives you a false sense of security otherwise.

        It only gives you a false sense of security if the browser tells you should have a sense of security. If the browser does not say that the connection is authenticated, then you get no sense that it is authenticated.
        If you have an encrypted but not authenticated session, then the browser should just display the web page, without the little lock icon, like it does with plain html. It should NOT put up a prompt trying to scare people away from the web page and making them click through 4 different buttons

    • by Timmmm (636430)

      Easy solution: Store self-signed certificate in DNS, access it using DNSSEC.

      • by Ash-Fox (726320)

        Easy solution: Store self-signed certificate in DNS, access it using DNSSEC.

        As an attacker, I'd just intercept all DNS requests, use a bunch of glue records to provide valid, but untrue DNSSEC records at higher levels which other DNSSEC records would validate against. Using a pregenerated seed, I could generate lots of records live on the fly extremely quickly too.

        Your DNSSEC aware resolver isn't going to do much against someone who can do a proper MITM attack.

        • by Timmmm (636430)

          I don't really follow you, but I'm pretty sure DNSSEC isn't vulnerable to MitM attacks, since that would be really really damn stupid.

    • A more rational mechanism should be ...

      This isn't about rationality. This is about the people who run and implement SSL being pig-headedly stuck in their ways, refusing to permit any other system except their own, and being in chronic denial about existing problems with that system.

      If you want a better encryption and/or authentication system for http traffic, you're going to have to code your own.

    • by itsdapead (734413)

      Wow, the end-user are warned as if it is more dangerous than plain HTTP site!

      Yes, a self-signed https connection can be more dangerous than a plain http one if you see the "https" or the "golden padlock" and assume you have a secure connection.

      You're confusing a specific tool (encryption) with the job (a browser establishing that a connection is sufficiently secure to justify displaying the "golden padlock" that non-technical users are told to look for before they enter their credit card details).

      To do the job properly the browser needs encryption and some way of confirming the i

      • by mwvdlee (775178)

        Yes, a self-signed https connection can be more dangerous than a plain http one if you see the "https" or the "golden padlock" and assume you have a secure connection.

        So this issue is not a technical but a social one.
        Technically, self-signed HTTPS is more secure than plain HTTP, but only by a small margin.
        But it could be percieved to be much more secure than it actually is.
        So, why not visually display both self-signed HTTPS and HTTP the same, instead of marking one in bright red?
        Then change the padlock with an open door for HTTP, a close door for self-signed HTTPS and a packlocked door for certified HTTPS?
        Currently self-signed HTTPS is visually presented to the user as l

        • by itsdapead (734413)

          So this issue is not a technical but a social one.

          Unless you see technology as a self-justifying end in itself, rather than as a tool to solve real-world problems (which often have social dimensions) that's not a useful distinction. Technology is pointless unless it accounts for the social dimensions.

          Technically, self-signed HTTPS is more secure than plain HTTP, but only by a small margin.

          In certain circumstances (e.g. a major bank or e-commerce site which could be a juicy enough target to attract sophisticated attacks) HTTPS with a self-signed certificate is actively suspicious and warrants a warning. Your browser can't distinguish these from

      • by David Jao (2759)

        Yes, a self-signed https connection can be more dangerous than a plain http one if you see the "https" or the "golden padlock" and assume you have a secure connection.

        The obvious solution is: don't display "https" or the "golden padlock."

        There's no reason why browsers have to display "https://" or even "http://". The average non-technical user doesn't care about the protocol; they just care about the "golden padlock." On the other hand, the average technical user already knows what's going on.

        Nobody here is arguing that self-signed https connections deserve a "golden padlock." That's your own straw man.

        The proposal is that we should treat self-signed https connect

        • by itsdapead (734413)

          There's no reason why browsers have to display "https://" or even "http://".

          Except, that's a significant part of the address. "http://somesite.org" and "https://somesite.org" could, potentially, point to different content (certainly different vhosts). Yeah - its a mess (often leading to redundant use of the protocol string, port number and "www" subdomains), but browser designers aren't in a position to fix that from their end.

          Nobody here is arguing that self-signed https connections deserve a "golden padlock."

          No, but browsers do need to advise non-technical users, who don't understand the technical distinctions, in the simplest justifiable terms whether a connect

          • by David Jao (2759)

            There's no reason why browsers have to display "https://" or even "http://".

            Except, that's a significant part of the address. "http://somesite.org" and "https://somesite.org" could, potentially, point to different content (certainly different vhosts).

            Web servers already display different content to users based on their geographical location or their login cookies or any number of state variables, and these content changes are not reflected in the URL. Your point means nothing.

            Sites using https generally do so because they want to exchange sensitive data, and the use of a self-signed certificate might indicate that a MiM attack is in progress, or (possibly more likely) that the site is being run by a cowboy outfit who can't be arsed to get proper certificates. So, a self-signed https connection is always slightly fishy (there are plenty of innocent explanations, but identifying those requires human judgement + technical understanding).

            This is a tautology. Since today's browsers are so alarmist about self-signed certificates, the use of self-signed certificates is automatically fishy. If you remove the alarmism then the amount of legitimate usage of self-signed certificates would increase dramatically.

            self-signed https = someone could be mounting a man-in-the-middle attack or you may have been spoofed/phished to the wrong website.

            The same ho

      • by gbjbaanb (229885)

        I'd put it slightly differently:

        You're confusing a specific tool (encryption) with the job (a browser establishing that a connection is sufficiently secure to justify displaying the "golden padlock" that non-technical users are told to look for before they enter their credit card details).

        confusing a specific tool (encryption) with a different tool (authentication).

        If you use a self-signed cert, you can guarantee that the guy sitting next to you using starbucks' wifi cannot read your 'hunnybunny' slashdot

    • by hitmark (640295)

      In the end it yet again comes down to public education, or lack of such, related to the subject.

    • by jd (1658)

      There was a time, not that long ago, when someone faxed Verisign a request for the private keys for Microsoft's SSL certificates and Verisign responded by handing the keys to them. No verification that the person was legit. DNS providers were just as vulnerable, with people sending in requests for zone transfers by e-mails with forged headers, faxes, letters on stationary not bearing any corporate logo. It worked often enough for there to be numerous scandals.

      As for China managing to trick the top-tier rout

    • by sjames (1099)

      Way back in the beginning, when we all still remembered using mosaic as our browser, I talked to a representative of Verisign. who assured me that nobody would ever lie about who they are because they have to sign a contract that says they won't. How very confidence inspiring!

  • Peter Guttman's take (Score:4, Informative)

    by kensan (682362) on Friday March 25, 2011 @06:45AM (#35609458)
    He makes some interesting points on EFF's SSL Observatory mailinglist: https://mail1.eff.org/pipermail/observatory/2011-March/000138.html [eff.org]
    • by Jesus_666 (702802) on Friday March 25, 2011 @07:28AM (#35609662)
      Let me get this straight.

      If I have the ability to obtain a cert for one site (say, mycompany.com), I have the ability to obtain entirely valid certs for any site on Earth? And the only way to counteract this is to have browser vendors blacklist my keys in their next update? And that's the foundation HTTPS stands on? And alternative schemes that may address the problem aren't even considered by the browser vendors?

      Wow. If I understand that correctly, web encryption is in a pretty bad shape as far as trustworthiness goes.
      • I don't think you can generate them yourself, I think what he's saying is that many CAs don't check if you're the owner of the domain before issuing the cert to you.

        The way to counteract it should be by dropping all CAs that don't follow a rigorous verification procedure before issuing certs from the browsers default trusted cert list; of course that raises different problems, like what happens to the thousands of websites that have certs issued by those CAs.

      • Not exactly. But if you manage to compromise or convince any of the built-in CAs trusted by browsers (or any of the hundreds -- or thousands -- of sub-CAs they delegate to) to give you a certificate for any website on Earth, and you can redirect your victims to go to your website instead of the real one, then yes. By compromising any CA where you can build a chain of trust to a trusted root, then you can impersonate any website (if you manage to get a certificate). Some of these CAs are actually owned/cont
  • by Anonymous Coward

    All we have is Comodo claiming they were from Iran, and an IP address. But why should we trust them? If you ask me, Iran fits in a bit too well as the bad guys.

    • by flak89 (809703)
      This is stupid many time there is a story about hacking and a IP coming from that 'third world country' (insert name here China[ ], Iran [x], Russia [ ], all other[ ]......), someone assume that a person local to that country did all the job. What if that IP in Iran was not secured ? What if that person actually used the internet and connected to that IP in Iran from somewhere else (doh). There is a ton of non-patched OS, vulnerable IP out there. Some peoples shouldn't use the internet (or for that matte
      • by mwvdlee (775178)

        Good point.

        If you were to use a hacked IP address to do something evil, would you do it using an IP address in a friendly country who'd gladly help the victim's country to track you down or would you go through an IP address in a country that hates the victim's country. Every little bit helps when it comes to security.

      • by Luyseyal (3154)

        You can't find me, I'm behind 4 boxxies!

        -l

  • Two more questions (Score:5, Insightful)

    by Lincolnshire Poacher (1205798) on Friday March 25, 2011 @08:03AM (#35609812)

    1. Why was a key-gen server connected to the Internet? Shouldn't certificates be delivered out-of-band, such as on a CD delivered to the indicated registered address?

    2. Why exactly do we still trust Comodo as a CA, when the like of cacert.org [cacert.org] cannot meet the "requirements" to be added as a CA in Mozilla products?

    • by RulerOf (975607) on Friday March 25, 2011 @10:06AM (#35610966)

      Why exactly do we still trust Comodo as a CA, when the like of cacert.org [cacert.org] cannot meet the "requirements" to be added as a CA in Mozilla products?

      $urely, you can't be $eriou$.

      • I am serious. And stop using the fucking dollar sign for your s's.

        • by Luyseyal (3154)

          I am serious. And stop using the fucking dollar sign for your s's.

          Whooosh. The GP simply meant that CA Cert has no money whereas Verisign et al. all have big pockets and probably share that with Mozilla. Whether or not this is true or if there is an actual technical reason, I have no clue. However, that was his/her point.

          -l

      • True, browser makers could have all release updates that removed comodo as a trusted root CA instead of just blacklisting the 9 certs that they think were signed. But that would have done the following:

        1) Made users of any site who got their cert signed by Comodo see a popup (which they'd probably suffer no ill effects from clicking through, further training users to ignore such warnings).

        2) next time a CA got hacked, they'd never admit it since it would mean certain death for the company. So instead of rea

    • 1. Why was a key-gen server connected to the Internet? Shouldn't certificates be delivered out-of-band, such as on a CD delivered to the indicated registered address?

      For the very same reason some resellers of this pitiful excuse for a CA deliver certificates to you before you've even scanned a single document proving you're authorized to ask for it (yes, seriously): Because it would be Bad For Business[tm]. People want to start their damn online shops Real Quick, and people who make these shops don't want to irk the customer by asking for lots of papers and delaying the setup. Like always, business efficiency and security do not mix well.

      2. Why exactly do we still trust Comodo as a CA, when the like of cacert.org [cacert.org] cannot meet the "requirements" to be added as a CA in Mozilla products?

      According to CAcert, we (or rath

  • I, for one, am grateful that this incident happened and the bad state of affairs gains publicity. Let's not forget, this has been possible for years and chances are extremely high, that it's been exploited by various Stasi's already....except nobody's really been noticing it.

    As far as I am concerned, the SSL CA model was really a DOA. Except with the 1990's gold rush of "e-commerce" nobody cared for anything but the quick and dirty solution. Which is, what we're still stuck with. Hardcoding "trust" is so fo

    • While I don't have ideal solutions either, I imagine, that real trust can only be established by tying domain certificates to actual people. Think GPG-style WOT. Think specifically Lawrence E. Page (CEO, Co-Founder and President, Products), Eric Schmidt (Executive Chairman) and Sergey M. Brin (Co-Founder and President, Technology) signing GPG-style Google's master key. Each company, depending on size, would then be their own CA and chances are, they have better control over what certs get created for which

      • > What happens when, say, Eric Schmidt leaves Google?

        Well, Eric Smith doesn't stop being Eric Smith and Google is still, well, Google. The signature is, for the time being, still valid since it says nothing except "This key really belongs to Google Inc. Sincerely, Eric Smith".
        The key would then be updated by having the new CEO sign it. A mechanism to put a time limit on signatures may also be useful (akin to having the option of having keys expire at some point).

  • Maybe a couple of dozens per year.
    If something goes wrong, e.g. there's a mismatch in names on the csr with what is in whois, all sorts of problems arise.
    The chaos in the processes is just mind-boggling sometimes.

    I'm glad we have our own CA and can self-sign.

    As said, these companies have just been lucky enough to be in the right spot at the right time to have their root-CAs int the browsers.
    Interestingly, at least Microsoft has a page detailing the requirements for the CA, should it wish to be part of

  • First time through I read that as "SSL Cert Weaknesses Exposed by Commando Breach"

  • Isn't Comodo a AV software company, I thought there were very few companies that truly had the power to hand on SSL certs. or I guess I am wrong, verisign, no? If any company can start handing out certs, especially to big companies that are public on the stock exchange, so that such a move could affect stock prices, I would say a better regulation needs to be in play....maybe there could be some
    international action on this, not some lone company (like comodo) that has access to such important security issu

    • by Machtyn (759119)
      Actually, Comodo is a certificates company. Their free firewall and, later, AV product was always just an afterthought for them. It wasn't until just the past couple of years that Comodo has allocated resources (with subscription service) for users of their Internet security software.
    • I thought there were very few companies that truly had the power to hand on SSL certs. or I guess I am wrong

      Open up your browser's configuration options and look at all of the root certs. I didn't count mine, but it looks like there are a several hundred entities that can issue trusted certs. Whether or not that qualifies as "very few" depends on what you would consider to be a large vs. small number.

  • Here are a couple Firefox addons that can help you avoid compromised certificates/CAs:

  • In going through the Cert Store in FF4, I discovered a number of them that were completely unchecked, indicating that the Mozilla Foundation/Org doesn't trust them. If that's they case, why in hell are they still in the store?

    If they're untrusted then remove them and start cleaning things up. If we actually need them, they can be installed at that time just like any other certificate.

My problem lies in reconciling my gross habits with my net income. -- Errol Flynn Any man who has $10,000 left when he dies is a failure. -- Errol Flynn

Working...