49

Just a matter of imprecise language that should be understood by everyone involved. You sign using the private key that only you have. The public key is not used, and the certificate is not used. In fact, maybe there is no certificate using the public key. The verifier verifies the signature using the public key, the certificate is not used. But the public ...


10

One thing may be added to Z.T.'s answer: the confusion is likely to be caused by the implementation of cryptography in Microsoft Windows (maybe other systems as well). In the administrative UI, both certificates and their correspondent private keys are managed via "Certificates" snap-in of management console. In .NET framework the class X509Certificate2, ...


3

Yes, there is a difference. On Windows, Google Chrome uses a built-in Windows Certificate Store when identifying the trust. Mozilla uses its own trust certificate store. Apparently, your internal CA is installed on Windows, but not in Firefox browser. You have to install your private root CA certificate into Firefox browser.


2

They are all sent together by the server All certificates, except for the root certificate, are sent together as one bundle. Technically, you may include the root certificate as well, but it will be ignored by the client. If the server only sends the "leaf" certificate, then it depends on the browser if they are able to somehow get the missing ...


2

How is it possible to change all the certificates? MITM (Man-in-the-middle). Your company is using some kind of proxy device that is intercepting all your requests and generates a certificate on the fly for the address you try to connect. The proxy basically acts like a CA, signing all the "fake" certificates performing MITM. Some vendors tend to call it ...


2

How is it possible to change all the certificates? The company is performing SSL inspection on the HTTPS traffic with a transparent proxy. This requires terminating the connection e.g. at the firewall and creating a new TLS connection for the client. This requires creating new (fake) certificates and signing it with an own CA. Why does my browser not ...


1

From the report by SSLLabs: Chain issues Incomplete This is a misconfiguration of the server: it is not sending the full certificate chain up to (but not including) the root certificate but instead only sends the leaf certificate. Specifically it is missing the intermediate certificate for RapidSSL TLS RSA CA G1. Without knowledge of the intermediate ...


1

Are the hex digits(starting as 46:ba:db:...) a digital signature of this root certificate(self-signed)? appended in the end of root certificate... You are mostly correct in that the signature is attached to the certificate. However, the “hex digits” aren’t simply stuck at the end of the file. Certificates are written in very specific standardized formats. ...


1

First, it is quite correct for a TLS/SSL server to send the intermediate aka chain cert(s) but not the root cert; see rfc 5246 sec 7.4.2 or the slightly more verbose version in rfc 8446 sec 4.4.2. As Z.T. mostly-correctly commented, -verify is the default for s_client (you don't need to specify it) and if you don't specify -CAfile and/or -CApath by default ...


1

UUIDs are allocated by the clients at random. This is their advantage - the space is large enough that a conflict is unlikely, but the protocol has to be robust enough to handle conflicts gracefully. Centralized management can be avoided. Do nodes generate their own UUIDs? Yes This would be dangerous since a naive or malicious node could generate an ...


1

DHT nodes randomly generates node ID by themselves. def generate_id(length): id = "" for i in range(length): id += chr(randint(0, 255)) return id def generate_node_id(): hash = sha1() hash.update(generate_id(20)) return hash.digest()` Node ID is generated randomly. Node ID is a 160-bit SHA-1 hash so the keyspace is 2^160. It is unlikely that one node ...


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