5
So who decides what CAs are trusted?
The browser and OS vendors do.
Why cant a regular users CA become trusted?
He can apply to be a public CA, but it is unlikely that the user is able to match all the security guarantees required by the browser/OS vendors for a publicly trusted CA. Even several commercial CA failed these requirements. But nothing ...
5
The best I can find is from a draft version 2 of X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP proposal, which later became RFC 2560. It states that:
The requester signature is used to authenticate the requester to the
OCSP Responder. It is used in conjunction with the requester
certificate extension defined ...
3
The connection to the OCSP responder does not need to be protected by HTTPS (it often is HTTP only) and the OCSP responder does not even need to be the authoritive source for the OCSP response, it can just forward responses it got from somewhere else. The signature instead is done by the authoritive source.
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.
3
I feel that a technical answer is not really possible here, or would really be accepted (as that is dealt with in the linked answer), but something more esoteric, if not the direct answer to your question, will at least provide interesting reading for some and food for thought for others.
Moxie Marlinspike has long held the belief that the CA trust model is ...
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 ...
1
Signing with a self signed certificate provides no value for the usual windows user.
The signature is invalid from the point of Windows.
The name of the signer is not shown in the elevation prompt. People who would be able to verify such a signature are equally able to verify e.g. a GPG signature which is more common in the open source community.
Signing ...
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
