46

Maarten Bodewes answer is correct but I think the heart of your question is a major hurdle people face in understanding certificates and CAs. I think it's worth elaborating on the part of how this works that I think you are missing. As stated in Maarten's answer, your computer/browser has been preconfigured with a set of trusted CAs. If you are running ...


28

There has to be some point where you trust something. Operating system come with 'root' certificate authorities. Those certificates are either installed when you install the operating system, or could be downloaded over a secure connection from at least one certificate installed with the operating system. You can (and many developers do) add your own root ...


11

No because the browser that you use has a build in security store, so it is perfectly possible to create a secure connection to the CA. Generally you can only request certs for your specific domain, e.g. by using a domain specific mail address. Generally you should also pay for the services which provider a small amount if traceability. Of course you ...


6

One idea I find useful in this context is looking at cryptographic systems not as absolute ways of achieving guaranteed security, but rather, as ways of reducing bigger problems to other problems that are hopefully smaller but still potentially substantial. Seen from this angle, you're basically grasping the following points: Public key cryptography is a ...


6

This is a very good question. Public-key certificates have the purpose to authenticate an assertion, namely that you are communicating with the entity that you intend to communicate with. Specifically, guarding against a Man-in-the-Middle attack (MitM) is done by authenticating the key material that is used. Your issue is the following. Say A and B want to ...


5

Due to the design of TLS 1.3 and different to earlier TLS versions the normal (EC)DHE key exchange is already finished once the server sends the certificate. They key server_handshake_traffic_secret used to encrypt the certificate and other handshake messages is based on the same key material as the keys which are used for the application data later. For the ...


4

The APK signing is well documented by Android, actually: You have here a high level overview of the process. A new APK signature scheme (v3) has been introduced with Android 9, that is detailed here. However notice the v2 can still be used. The documentation about v2 has a good overview of what is contained in a signature block in an APK: For each ...


3

I would like to address Maarten Bodewes' answer. Although Extended Validation (EV) certificates, in the past, may have improved the legitimacy of the website you're browsing by requiring further human identity verification, this does not mean that it hasn't been exploited for phishing. One downside of EV certs is the human verification part: human are prone ...


3

OCSP is not susceptible per se to MITM attacks, but it does have other problems: Most browsers used to soft-fail, e.g., if they couldn't get the OCSP response for some reason, it allowed the connection to go through. So the attacker only needed to block the OCSP response. Privacy issues: an attacker can see the OCSP query going through and can gain some ...


3

Each CA has their own revocation list. When your device validates a certificate, it determines what CA was used to sign it, downloads the CRL (whose URL is included in the CA certificate) and checks if the serial number of the certificate is included in it. Since all certificates have expiration dates, then any certificate in a CRL can be removed from the ...


3

In a public-key infrastructure, there are two ways a public key can be trusted: either because it's signed by a certificate authority that you trust, or because you already have it in a list of trusted public keys. That's where the chain of signatures ends: in a list of pre-trusted public keys. These pre-trusted public keys are usually called “root CAs” or “...


3

You're confusing a lot of things: Alice and Bob agrees on a shared private key that is to be used to encrypt You cannot have a "shared private" key; sharing and keeping things private are opposite terms. That would be called a secret key, as it is kept secret between Alice and Bob (some books confuse these terms as well, but yeah). To reach private ...


2

Untrusted certificate or expired certificate? If you go strictly by RFC 5280 ordering, "untrusted certificate" should be returned. More specifically section 6.1.3 starts with The basic path processing actions to be performed for certificate i (for all i in [1..n]) are listed below. (a) Verify the basic certificate information. The ...


2

Cryptographic sealing is the application of asymmetric cryptography to encrypt a session key so that it cannot be used-- until it is decided to remove the seal and use the key. It is a protection mechanism. See this description from Oracle: Sealing the symmetric key involves creating a sealed object that uses an asymmetric cipher to seal (encrypt) the ...


2

The Key Usage field is represented as a bit string, where each bit represents one of the options, so that multiple options can be set. The value 6 it's just the constant of the bit position that identifies "CRL Signing". From RFC 5280: KeyUsage ::= BIT STRING { digitalSignature (0), nonRepudiation (1), -- recent editions of X.509 ...


2

The end entities (phones, PCs, etc.) doesn't store the CRL files. I mean doesn't store permanently. :) In the Certificate there's a field called CRL Distribution Points where the CRL file could be downloaded. These files are issued by the CA and contains the list of revoked certificates. While the validation process this file is downloaded and checked ...


2

There are several great answers here that give a lot of information about the PKI system and Certificate Authorities in general, but none have specifically answered the question, "who vouches for the Certificate authority?" The answer to that question is that the Certificate Authority (CA) vouches for itself through a comprehensive annual audit. The audit ...


2

This is an insightful question, and correctly focuses attention on the hard part of the problem. One part of the answer is that the Certificate Authority can be more stringent than an ordinary user would be in verifying things since that's their whole job. For the Web PKI (certificates used by web sites and most stuff you use on the Internet) there are ...


2

Plain text of data, including server's public key Yes, and many other public information, including something identifying the holder of the public key (perhaps in the Common Name field). Signature of hashed version of plain text Yes, except that the correct semantic is: Signature of the plain text. Building and verifying the signature includes ...


1

My answer is: nobody. The various public CA either do not guarantee anything or have a rather limited guarantee. As for the certificates stored in your browser, I don't think it would be too difficult for hackers to install a fake certificate of their own. The public PKI/CA structure is in my opinion "better than the alternatives" but not much more than that....


1

There have been several cases where root-CA had been compromised. But one part of the whole mechanism is that the root-CA work in a network together. Their CA-ability hangs on held certificates of trust, signed by other root-CA. As soon as it became apparent that one of the CA wasn't trustworthy the very same mechanism "kicked" them out, as the certificates ...


1

Yes, it is possible to generate a self signed certificate. If you've got a private key that can sign with it using the required signature algorithm then that should always be possible. Tool usage (such as openssl, which can be used to generate self signed certificates) is off topic here, but basically you just create the To Be Signed (TBS) part of the ...


1

There are no TLS ciphersuites using CAST, so you can determine that one without looking at any actual data of any kind from any connection(s). Yes, you can always tell passively (merely by looking) at a TLS handshake the selected ciphersuite. Note ciphersuites containing 'SHA' (meaning SHA1) use it only for the key derivation (called PRF through 1.2), and ...


1

HMAC solves the collision problem of hash algorithms by mixing in a pre shared secret. No, HMAC is a construction of a message authentication code based on a hash function. Specifically intended to be used with hash functions based on the Merkle-Damgård construction. Can't we just use the pre shared secret to symmetrically encrypt data and leave out the ...


1

In practice Cross Certification is rare, instead, certificate consumers trust multiple CAs. For example, Mozilla includes 154 different trusted CAs by default with their browser. As to the process of cross-certification, it involves a CA signing other CA's public key. It can be one-way or cross-certified.


1

It should be pretty much the same. If you can sign a CSR with RSA you can sign with ECC. The exact same data is signed, what changes is: The signature algorithm should be the right OID (e.g. ecdsaWithSHA256) The signature value must be the ECDSA signature encoded as specified in SEC (i.e. an ASN.1 sequence of the two integers in the signature) The public ...


1

The Full Response has additional information over and above the P7B file with information such as the CMC response and some chaining information. I'd go as far as to say it's not really relevant in day-to-day use. You can look at them all with certutil.exe and make your own mind up though - simply pipe the outputs to a text file and read at your leisure. ...


1

The strong authentication protocol referred to in the book is defined in the Annex N of "X.509 (10/16)" published by the ITU https://www.itu.int/rec/T-REC-X.509 Here is an excerpt of the standard for the two-way and strong three-way protocols: Annex N Considerations on strong authentication Strong authentication makes use of PKI as specified by ...


1

OpenSSL source includes a file crypto/objects/objects.txt which has a list of all the object names/oids that OpenSSL understands. It's definitely parsable; there's a perl script with it which parses the file to produce openssl's obj_dat.h header. OpenSSL in 1.1.0 and later supports the "list" argument. openssl list -digest-algorithms produces: BLAKE2b512 ...


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