Could someone explain to me the following:
Who creates the public key during CSR? Is it CA's responsibility to offer it or it depends on the certificate requester? If the latter is true, in which way the browser client may include in its truststore this public key as to verify the SSL certificate sent from server? If the former is true, how many public keys a CA owns and in which way are all these keys known to the browser client? This is a point I cannot find or give a satisfactory answer since I cannot imagine the client holds a database of an enormous number of public keys...
Thank you very much
Public and private key can only be generated as a pair. Since the CA should not know the private key, the requester has to generate that pair himself.
While the browser has to store the public key of every trustworthy CA, it does not have to include the public key of every https-enabled website like prettykittens.org in its truststore.
So how does the client judge the authenticity of the site?
During the SSL-handshake, the webserver sends its public key and a message signed using CA's public key that roughly says "This is Company XY's public key for prettykittens.org" (aka a certificate). Then the browser only has to verfiy the signature using the CA's public key and is good to go.
Related
I am implementing the SPKI Pinning to my mobile apps and i wonder if the Subject Publish Key will change when I renew it with another CA?
I still use the same CSR to generate the cert. People say that the Public Key will be the same if we use the same Certificate Signing Request file (CRS), But I'm not sure if CA is also a factor.
Short answer is: no, it shouldn't change, provided you did things properly.
It is recommended that when you specify a SPKI HTTP header you should provide at least two Subject Public Key Information (SPKI) fingerprint of private keys in your control (one for production and other for backup). Now, as reported here, it is a common practice to specify the SPKI fingerprint of well known CA in the case of private key loss, but it renders HPKP invalid because if the CA is compromised then you are basically saying "trust the CA issued certificates". That is why recommendation is to provide the SPKI fingerprint of your own public keys: one for common usage and another in case of private key loss.
Thus, provided you are specifying in the SPKI HTTP header of your own public key, whenever you generate a new certificate with another CA (either with the same CSR or a new one) your public key will be the same and the SPKI will still be valid.
I have client-side generated a digital signature(JavaScript). The signature is then verified on Java back end. To verify the signature I am passing to the backend - (signature value, public key and message for verification). So far so good, but then the question arises - What if someone performs a man in the middle attack? He can easily generate a signature and send his - (signature value, public key and message.). So in a sense, this makes my current implementation not secure enough.
How can I avoid this? As far as I researched I have to verify that the public key sent is coming from the appropriate client and this is done through CA (Certificate Authority). However, in my case, I am doing this as a final project in university and I am not sure how to approach this problem.
Should I generate the public key certificate on the client side and send them along with the public key? Is it possible to generate self-signed-certificates on client-side and then verify it on the back-end?
What if someone performs a man in the middle attack
A MITM could replace the signature and the public key
How can I avoid this?
Mainly use SSL/TLS and/or...
As far as I researched I have to verify that the public key sent is coming from the appropriate client and this is done through CA (Certificate Authority)
If you use a Certificate Authority, each certificate is signed with the private key of the root CA certificate (or a subCA), so a MITM can not create a valid certificate because he does not own the root private key.
At server side, you can validate that the signature has been performed with a private key that corresponds to a certificate issued by the CA. Note that in this case you are working with certificates, not just with public keys ( a certificate envelopes a public key).
I am doing this as a final project in university and I am not sure how to approach this problem.
You have explained your solution but not the background. I mean why do you decided you need a digital signature? without that information I can not advise you.
Should I generate the public key certificate on the client side and send them along with the public key?
Read my previous comment
Is it possible to generate self-signed-certificates on client-side and then verify it on the back-end?
Yes, of course. You can generate a key pair at client side and associate the public key with the user's account during the registration process (using a secure channel)
This way you do not even need a password. The digital signature with the private key is the authentication proof. Using a CA is optional. The CA could issue a certificate containing the public key, but fot this scenario is not required
I just got myself an ssl certificate for my domain and it works fine, but I'm using the bitcoin payment protocol and I need to sign the messages with my public key before sending them but how are messages signed with an ssl certificate and what tools should I use?
EDIT
It seems what I actually need to do is sign a message using the public key of my ssl certificate issuer.
Thanks in advance :)
The protocol specification must be incorrect. Digital signatures are signed with your private key.
Your certificate needs to accompany the message, and probably be included in the signature. Use the java.security.Signature class in association with your private key, possibly loaded from your KeyStore.
You may need to purchase a signing certificate: an SSL certificate may not be strong enough for bitcoin.
A signature using a public key is completely worthless. Anyone can do it. You sign with your private key. This is legally equivalent to your signature: only you can do it, and anyone can check it by verifying it with your public key, which is why the public key must accompany the signature; and at the same time they can establish whose signature it is, via the certificate which must also accompany the signature.
Or else bitcoin is radically insecure.
Mystery solved, the message is to be signed using the bitcoin public key with the signmessage "bitcoinaddress" "message" bitcoin command.
I have a python application running behind an SSL nginx server.
In the nginx config I use "optional_no_ca" because I want to accept self signed certs.
My question is: can I blindly assume that the connection initiator is also the owner of the private part of the public key that I get in the certificate.
I.e. can I use the public key as the user id?
Yes, if the client authenticates with a certificate on SSL/TLS level, this confirms that the client has a corresponding private key.
Yet I would question the approach of using public keys as user IDs. Disclosure of the private key in this situation would need to replace the keypair and thus the user account should be discarded as well (if it's identified by the public key).
Another aspect is that the public keys and client-side certificates are not handy for users to manage.
Please help me fill out the blanks here -
The server keeps its private key and the public key is shared to the users. So the client trusts the content thats coming from the server using the public key. How does the client encrypt the contents he is sending back to the server ?. Using the public key of the server ? or does the client send a autogenerated private key and encrypts it using the public key which is then decypted by the server along with the message and used for furthter communication by both parties.
A Public and a Private key is required to do ssl communication. This Key pair is generated using a self signed certificate ?. How can a single self signed certificate contain both public and private keys.
One more thing On message level security -- im looking at a current configuration and am pulling my hair out -- Using IBM Ikeyman to look at the producer and Consumer JKS files-- for Message level security(Digital Signing) there is a Personal certificate at the Consumer and a Signer certificate at the Producer ... Isnt this the other way around? Is this current configuration incorrect --- Both the keys are same by the way.
The server keeps its private key and the public key is shared to the users.
Correct.
So the client trusts the content thats coming from the server using the public key.
No. There is no 'so' about it. The client trusts the server certificate because it is signed by someone he trusts, and he knows it belongs to the server because the server provides a digital signature that the client can verify, which only the private key owner can do. Therefore he knows that the server owns that public key.
How does the client encrypt the contents he is sending back to the server ?.
The client and server negotiate a shared session key independently using techniques described in RFC 2246. For the most part they don't involve PKI at all.
Using the public key of the server? or does the client send a autogenerated private key and encrypts it using the public key which is then decypted by the server along with the message and used for furthter communication by both parties.
Neither, see above. This is quite a large subject.
A Public and a Private key is required to do ssl communication.
No. One of the parties must have a private key and a corresponding certificate that the other party trusts, otherwise the communication is insecure.
This Key pair is generated using a self signed certificate
No. The statement doesn't even make sense. Key pairs are generated first, nothing to do with certificates yet. The certificate is a wrapper for the public key.
How can a single self signed certificate contain both public and private keys.
It can't, and it doesn't. Self-signing doesn't have anything to do with it either.
Public-key encryption 101:
The public and private keys form a pair: each key in the pair can decrypt messages encrypted with the other, but cannot decrypt messages encrypted with itself. If the client can decrypt a message with the public key, it knows the message was encrypted by the owner of the public key. Conversely, a message encrypted with the public key can only be decrypted by the owner of the private key.
The basic idea is that the client generates a key for a symmetric-key cypher, encrypts it with the public key, and sends that to the server. Both sides then use that symmetric key and cypher for the majority of the communication.
In SSL communication,when the client wants to interact with some server, the server sends its public key. Always remember a certificate is nothing but a public key with a bunch of supporting information.
The problem here is any hacker can masquerade as a server and can block the communication between server and client. So the server certificate must be signed by some certificate authority. The client only believes the server certificate if it is signed by a certificate authority.In that case the hacker in between can not masquerade as a server because its certificate will not be authenticated by the certificate authority.
So client accepts the certificate and gets the public key of server. Now the client can send its public key encrypted by the public key of the server. Since this encrypted message can only be decrypted by the private key of the server so only server can decrypt it.
But the use of public key and private key over the ssl communication can slow down the connection very much because these keys lengths are 1024 or 2048 bits.
So practically what happens is instead of sending its own public key, the client sends the symmetric key encrypted by the public key of the server. Server decrypts it with its private key and it gets to know the symmetric key. Now the further communication happens with this symmetric key encryption and decryption.Since no third party gets to know the symmetric key, the communication will be secure.
Remember symmetric key lengths are generally 64-128 unlike public keys hence less the time for encryption and decryption.