Tag Info

Hot answers tagged

6

... But in reality, a self-signed cert is not significantly less secure than a cert signed by a CA - in the sense that your traffic is encrypted and sent to the web server and decrypted there. It just means that no one "trusted" checked the identity of the webserver in question. This just is a very important part. If you don't verify, that the peer you ...


4

There is no global directory of all issued certificates (X.509 was designed to support the Directory, but it never existed in practice). You will have to contact "all CA" and ask them nicely. Basically, this would mean going to their site, and using the "I lost my password" feature so as to regain control of your account, if it exists. Details vary depending ...


3

Partly solving the underlying problem, you may use Public-Key-Pins header to restrict which certificates are valid for your domain (so a stolen certificate could only be used by a man-in-the-middle would on the first connection to your site). You can also use Public-Key-Pins-Report-Only to get notifications for failed Pin validation. Both headers are ...


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 ...


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 ...


1

The "right" way to think about renewals is to ask yourself why you want to renew. As I understand it, you have a root CA which is hardcoded in some application installed in the clients. Moreover, the clients themselves own certificates, presumably issued (directly, or indirectly through an intermediate CA) by that root CA. This hints at some mutual ...


1

"Web of Trust" in X.509 formats have been occasionally tried. For instance, Thawte tried it but gave up. For a Web of Trust to "work", you need two things: "Relying parties" (in the HTTPS case, this means Web browsers) must implement the verification protocol which checks the WoT relations. Sufficiently many participants must join the system. A WoT ...


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 ...


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. ...



Only top voted, non community-wiki answers of a minimum length are eligible