Tag Info

New answers tagged

9

First of, CRL do not cover root CA. By definition, a root CA is a root: it has no issuer except itself. A CRL conveys revocation information, which is a way for a certificate issuer to announce that a previously issued certificate should be considered as invalid even though it looks fine and its signature is correct and everything. Thus, a CRL that talks ...


0

I think you are assuming Google is not trusted or that this is an oversight in the Certificate Authority trust model. I don't think there is a problem with Google running a certificate authority. Perhaps they can choose to constrain it to their own domains, but nothing stops them from entering into an agreement with an established Root CA (or buying on!) ...


1

Trusting a CA means that you trust the CA for all certificates issued by this CA. But because all CAs are treated the same by the browser (except for EV certificates) any CA could create a certificate for any site. This means it is enough if a single trusted CA is not as trustworthy as needed and this kind of trust problems happened several times in the ...


2

The PKI model works on the trust you can give to the initial third party. Namely, the root CA. If you trust the root CA, you should import their root certificate, so that any certificate they issue (sign) will be automatically accepted by your system. If you do not trust the CA, well there is nothing more you can do. So why would you trust CAcert.org ? ...


-3

Your website is secured with the SHA-1 algorithm. The SHA-1 algorithm is now outdated and Google Chrome & other web browsers have already quit their support for it. The lower hash value and key length lets hackers crack the website easily. Chrome 38.x users see the website as secured without any warning message, but Chrome 39, 41, 42, .... users will ...


5

You don't need to get another new certificate. In order to resolve this issue, you need to just reissue your certificate with SHA-2 signature. That's it.


13

Google blogged about flagging Certificates using SHA-1 here -> Gradually sunsetting SHA-1 There's no reason to get a new certificate yet as Chrome won't be actually blocking the certificate just treated as “secure, but with minor errors”, I believe that some issuers are offering to reissue certificate but as always, YMMV.


1

I found a solution as I was looking for; http://blog.engelke.com/2015/03/03/creating-x-509-certificates-with-web-crypto-and-pkijs/ But I'll try pem modulus at first. Because it works on back-end and seems more simple.


0

From what I read in the comments and in chat I think this is related to timestamping. The driver has been signed at a time the certificate was valid. That signing time was confirmed by a certified timestamp server. In that case, the driver is considered as trustworthy, since everything was fine at the time of signing. To check for a timestamp, open the ...


2

There are two chains up to Verisign Class 3 G5. At one point, Verisign was chaining to that root via a longer chain, and some OSes were confused when walking up the AIA versus walking up the chain handed by the server to the client. This sounds like a significant problem, especially since the combined Symantec properties are the largest tier 1 CAs. I do ...


14

Solved. The problem was indeed triggered by installing Apple Mavericks/ML Security Update 2015-004. As mentioned in this Apple release note, it included updates to the certificate trust policy. There was a duplicate certificate installed (with a wrong serial no.), removing it fixed the problem. The serial number for the cert as published by Apple matched ...


2

It should be noted that there's nothing wrong with the certificates from a TLS or x509 point of view. The CA/Browser forum applies to CAs issuing publicly-trusted certificates that subscribe to those guidelines. Not all TLS or x509 use cases involve public trust. An internal government or enterprise CA, for example, might reasonably choose to completely ...


2

The structure is all wrong. If Google uses this intermediate cert only for signing Google-owned domains (which I think is the case) they can't do it with a restricted path certificate, because they need to sign google.com and google.co.uk and gmail.com and even com.google now that they own that TLD. In my opinion, the PKI was poorly designed to begin with, ...


1

It's possible that this CA certificate is linked to GeoTrust's root certificate by way of Geotrust's 'GeoRoot' service, which "Allows Organizations with Their Own Certificate Authority (CA) to Chain to GeoTrust's Ubiquitous Public Root ". See ...


0

Why does the subordinate CA lack the name constraints? Because browsers would ignore these settings anyway. Currently there is no technical way to restrict which certificates sub-CAs can issue.


0

Just some of my two cents: I could imagine that public key pinning be used in scenarios where it can be difficult to update the application in the event that the certificate is renewed (for instance in embedded systems or IoT applications). Otherwise, certificate pinning would be more convenient. If the public keys are generated with sufficient entropy it ...


2

No, you cannot use the same certificate for both server- and client-side SSL authentication. (Well, technically, you can - it won't break anything - but it means that the server private key will be known to N clients, each of which can then impersonate it, so that's just not going to work out.) If you wanted to do Client SSL authentication, you'd want to ...


0

Short of asking the Certificate Authorities yourself (preferably with a secondary list of valid CRL and or OCSP download URL's lists) one by one I know none. You could script that, or you could recreate the Repository and create a hash of it. Also checking if the checksums are valid can give you a clue (although it does not show a replaced certificate / ...


2

Actually, there is an often unused (at least on the web) optional part of SSL/TLS that allows for client authentication. It is generally not used on the web because the server doesn't really care if the client is who they say they are - they just need to have the proper credentials. Additionally, imagine the nightmare of having to verify every client in the ...


1

"fakebook.com has acquired a certificate from on the trusted CAs" : Normally (and I said normally, because to say it so "the world isn't perfect") this step should not happen. A really trustable CA should benefit from specific services from third-party societies (like Netcraft) so, when you try to register a new domain name, they will automatically check it ...


5

is it trust-worthy because the CA authority did a background check on them? No. A SSL certificate is comparable to a passport: it says who the person is and which country the passport issued. But it does not say how trustworthy the person is. The main use of the certificate is to make end-to-end encryption possible, that is protecting against ...


0

Comodo, which was involved in this fiasco, trusts the following email addresses for domain verification: admin@ administrator@ postmaster@ hostmaster@ webmaster@



Top 50 recent answers are included