Tag Info

New answers tagged

1

I think it's more of a security concern as highlighted in 1. CAs like VeriSign uses the two-tier hierarchy (or trust chain) concept to provide more security. This is because the roles of the primary and secondary CAs are separated and may be hosted in different servers, maybe in different geographical locations. So, most probably more precautions are ...


0

The "DO NOT TRUST" is actually in the certificate itself as created by Fiddler. Fiddler is able to interpret HTTPS connections by acting as an HTTPS proxy. When you connect to a site via HTTPS, Fiddler produces a certificate that claims to be from that site and then accesses the real site. This way Fiddler can see the traffic, but your browser still acts ...


0

The way that I understand that Fiddler (And similar proxyies such as Burp or OWASP ZAP) work is that each installation generates a unique root certificate which it then uses to generate certificates on the fly when you have it assigned as a proxy, so you can intercept and modify traffic flowing over this connection (the purpose of the software). As the root ...


3

It's safe as long as you understand the implications. Fiddler acts as a proxy / man in the middle to intercept and decrypt traffic between you and the target. For SSL sites, it does this by dynamically generating an SSL certificate with the name of the target. The problem is that your browser will not trust certificates issued by Fiddler, hence the ...


5

From RFC 5280 3.3 Revocation An entry MUST NOT be removed from the CRL until it appears on one regularly scheduled CRL issued beyond the revoked certificate's validity period. If you have a lot of changes (people leaving etc.) it's best to not make the certificate validity too long otherwise the CRL can grow large (some CRLs are > 30MB which ...


2

Expiration date is "baked" into certificate itself, so even if time on client is incorrect this wouldn't cause server to mistakenly accept the certificate. Server clock, on the contrary, have to be correct. Now, whether or not it is safe to remove expired certificates from the CRL depends on how server verifies certificates and, in particular, whether it ...


2

Pre-Snowden, I would have dismissed this question as being in the "tinfoil hat" category. Unfortunately, the NSA's pervasive misconduct (not to mention that of its "Five Eyes" junior partners, e.g. GCHQ, CSIS, and whatever the Australian and N.Z spook agencies are calling themselves these days), does indeed raise a troubling question. The specific ...


2

The "ValiCert Class 2 Policy Validation Authority" root from 1999, along with about a dozen other roots from ValiCert and other CAs, are being phased out because they're only 1024 bits. 1024-bit RSA is increasingly close to being breakable1, so the community has decided to get rid of them in an orderly manner by 20112 to prevent a major security incident and ...


1

Take into account that there are server software (like IBM HTTP Server) that will not start at all if the root CA is not included in the keystore.


1

I send the root when it is convenient to do so. If the client trusts the root, then it makes no difference whether you send it or not. When the client does not recognize the root, in my experience the MS Windows client produces much less confusing diagnostic messages if the untrusted root was provided in the chain. As for how it knows what root to use if ...


1

what does a browser use to compare against for validation since the server won't be supplying its root cert during the handshake The whole idea of certificate checking is that the clients has some root certificates it trusts (shipped with the browser or OS) and that it validates the certificate the browser sends against this local trust anchor. This ...


3

The server always sends a chain. As per the TLS standard, the chain may or may not include the root certificate itself; the client does not need that root since it already has it. And, indeed, if the client does not already have the root, then receiving it from the server would not help since a root can be trusted only by virtue of being already there. What ...


2

You can add, for example the -sha256 flag to the OpenSSL command line when generating the CSR. I don't believe any CA will change how they sign your CSR based on this, and it certainly won't affect the certificate chain. They're not resigning the cert chain for each key, the only signature operation they do is on your CSR itself. Any intermediate/root CAs ...


1

Your point 4 is a bit unclear: is it a problem if clients start to claim that they did not receive the "material", while in fact they did ? If it is not a problem, then what you basically need is: A SSL connection to your server. The server's certificate must be recognizable as valid by the clients. Since the client software is under your control, you ...


1

You are correct that if the attacker gets onto your proxy, then all systems that trust the proxy are vulnerable in some way. Your proxy is now as valuable a target as the sum of all the traffic flowing to the machines that trust it. What you can do to help limit your exposure is to restrict the intended key usage on your root certificate, limiting its use ...


1

The certificate file by itself does not suppose a threat. When you load it into your browser it only lists it as a trusted source. That means that any certificate signed by that issuer should be trusted and thus allow you to connect to a site. Without access to the corredponding private key (which should be only present in the proxy), it cannot be used to ...


1

Let's abstract from a .cer or .pfx for a moment. What is a certificate? It is something tying public key to a name (oversimplification, but should be OK for this question). Certificate is signed by a third party (certification authority) which certifies that this public key "belongs" to this name (e.g. www.example.com). Now, when web browser connects to a ...


1

The certificate is available as long the SSL connection is open by calling SSL_get_peer_certificate, see https://www.openssl.org/docs/ssl/SSL_get_peer_certificate.html. It is no longer available after SSL close.


1

A certificate, properly named, does not include a private key. A certificate contains a public key, and an identity, and is signed by a Certification Authority. Unfortunately, a number of widespread documentations use the term "certificate" to designate the combination of a certificate and the corresponding private key; this spreads confusion. A certificate ...


0

I assume your question was: Does a computer ship with CA certificates preinstalled? This is the case. The standard OEM installation of Windows (and all other OS) on a computer ships with a preinstalled list of trusted certificates. Here are the lists for Windows and iOS. Even if you had CA certificates in your store that were preinstalled, they ...


1

First step: forget all about encryption. There is no encryption in certificates. There are digital signatures. Digital signature algorithms, when first invented and published (in the late 1970s), where unfortunately described as "encryption with the private key", which is a flawed analogy, that does not actually work, and entails a heavy dose of confusion. ...



Top 50 recent answers are included