Skip to main content
12 events
when toggle format what by license comment
Mar 6, 2020 at 17:58 comment added RRHS Perfect!! Thanks again for all the quick responses..
Mar 6, 2020 at 17:57 vote accept RRHS
Mar 3, 2020 at 9:18 comment added ecdsa Step1/Step2 can be combined by using the first command (which fetches the certificates via SCEP and installs them) if the fingerprints can be verified somehow. The root CA certificate is self-signed by the associated private key, intermediate CA certificate are signed by the issuing CA (basically like end-entity certificates). Step3: No decryption is involved when comparing fingerprints, these are simple hashes (usually SHA-1) of the public keys contained in the certificates. Decryption is required to verify signatures in the certificates themselves (i.e. to verify the certificate chain).
Mar 3, 2020 at 8:46 comment added RRHS Ill just brief up my understanding. Please let me know if im right or wrong as well. Step1: The Device gets the CA public key through some out-of-band means. Step2: The device installs the CA certificate which is signed using the private key of the CA server. Step3: The device decrypts the signed fingerprint using the public key of the CA obtained through some OOB means and verifies the hash by applying the same hash algo to the cert and then comparing it with the same hence the trust is established. Step4: Request for the End entity certificate. Thanks a lot for the answers.
Mar 2, 2020 at 8:21 comment added ecdsa As I said in my answer, it's up to the device admin that installs the CA certificates to verify they are correct and can therefore be trusted (e.g. by comparing the fingerprints of the public keys with those provided out-of-band by the CA maintainers, or by manually installing the already verified CA certificates). The CA certificates (in particular the root CA) are the trust anchors and this trust has to be established manually before end-entity certificates can be issued or even verified.
Mar 1, 2020 at 16:41 comment added RRHS But if the public key of CA is embedded in its certificate, how does the client know that the CA server can be trusted? Isnt the public key the only way to decrypt teh encrypted certificate hash and then inturn verify that the hash is the same as what the client expected or calculated it to be? Does that mean, the public keys are all exchanged(Clients to CA server, CA server to Clients) before any request or negotiation happens?
Feb 28, 2020 at 11:03 comment added ecdsa No CA certs are issued for the device. They are merely installed in its trust store. The public key of the CA is embedded in its certificate, which are, as described, either downloaded via SCEP, or manually installed. In general (and as I mentioned the diagram is for the general case), CA certificates are installed in the trust stores of operating systems and browsers etc. I thought I explained the flow (first get the CA certificate(s) as trust anchor, then request an end-entity certificate for the device).
Feb 28, 2020 at 10:39 comment added RRHS And also, am I right in saying that the there are 2 different certs getting sent from the CA server. One is during the CA cert enrollment and one more is during the local certificate request. "AND WHAT DOES THE CERT ACTUALLY CONTAIN IN BOTH THE STAGES"? I think I may have confused myself in the worst possible way. I just don't understand the flow of this process. Could you please explain it.
Feb 28, 2020 at 10:33 comment added RRHS "First, the diagram you posted just shows the general process of a CA issuing a certificate" --> Does that mean, the process is the same for the local cert enrollment and the CA cert issue for the Devices? "and a client verifying that a certificate is issued by a specific CA (by verifying the signature using the CA certificate's public key" --> When and how does the device receive the public key of the CA server? "it has to be in possession of its certificate beforehand." --> How does the device get its. cert before hand as thats what is being requested in the first place.
Feb 28, 2020 at 10:25 comment added ecdsa Could you clarify what confuses you?
Feb 28, 2020 at 10:19 comment added RRHS I understood the 2nd part related to the local certificate. But i still have some confusions.First, the diagram you posted just shows the general process of a CA issuing a certificate (by signing a hash of the certificate's contents with its private key
Feb 27, 2020 at 9:20 history answered ecdsa CC BY-SA 4.0