With Openssl, how to generate a certificate request from a public key? - cryptography

With Openssl, how could I create a certificate request, starting only from a public key ? (programmatically or not).

It is not possible, using openssl or any other software, to generate a CSR without the private key because a CSR must be signed with the corresponding private key.

I don't think this is possible with OpenSSL, because the CSR is always signed with the private key. But I found an online tool called PKIWidgets which is able to create a "stand-alone" CSR.
You might also find more information in the CSR FAQ.

Related

Digital signature man in the middle attack prevention

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

ssl certificate- get private key from csr

Is it possible to export private key from CERTIFICATE SIGNING REQUEST?
I have a CSR file and some CRT files. Now I have to install this certificate. How do I do it or do I need some other files in order to install this certificate?
No you cannot export the private key from CSR because the CSR does not contain any private key.
You need another file that has a private key and if you have that you won't need the CSR to extract the private key.
You create CSR from a private key not other way around.
In general the process goes like
You create private key
You create CSR Hand CSR to Certificate Authority aka CA
CA will give you a Certificate
you are good to go with you private key and with certificate depending upon client e.g. PHP Curl is fine with it
You may also combine your private key and Certificate using PKCS12 format depending upon your client requirements.
First comes the private key generated by you. openssl is a great utility for this.
Then the public key can be generated from the private key, or a Certificate Signing Request file can be generated which contains the public key in addition to extra information about your company and your site.
That CSR is pasted (using the Godaddy or Digicert methods) into a certificate request form on their respective sites. There is a verification process which may happen automatically or by email.
Then they'll generate a cert which you can use -- the public key is part of the cert.
So notice that you started off with a generated public private key pair, and ended with a cert private key pair.
If you're talking about a 'client' (general rule, this process can go back and forth), in general it will use just the cert, which is sent from the server during TLS (ahem, was SSL) negotiations. Or a utility program will use a cert when talking to a 'server' that is paired with it. The server is the one that will decrypt with the private key what was encrypted using the public key embedded in the cert.
So if all you have is a cert, in general you are talking about a client that knows which server it is going to go to.
But usually you are talking about a server, in which case the private key is probably already installed, and all you are doing is updating the cert. So if we are talking about a webserver, there are going to be configuration files which will point you to where the 'old' cert is that you are replacing. You'll also see where the key is, but that wouldn't need to be replaced unless you started the process by generating a new key. If so, then you'd also replace the old key with the new key.
I ended up in the same situation when I was given a new certificate from a third party for an existing CSR.
The initial CSR was complete and certificate was installed in Windows environment. When I tried to import the new certificate it was imported without its private key. This link was very helpful:
https://learn.microsoft.com/en-us/troubleshoot/iis/assign-certificate-private-key
Basically when creating a CSR (from IIS etc.) Windows stores the private key internally. When importing the certificate to the same machine, Windows automatically signs it with the private key.
When you import it for a second time. You have to use the command:
certutil -repairstore my "SerialNumber"
Where Serial number is the imported certificate's serial number

Managing and storing wildcard certificates

I've purchased a wildcard certificate. How do I keep it safe while making it generally available to all of the projects I need to deploy?
Your private key should make your wildcard certificate safe.
As per rule, the CSR must be generated to where you want to install the certificate. You can install a certificate to different server types. Knowing that, for every server, you will need to generate a CSR. For every CSR you will have a unique private key.
This private key is also protected by the password that you initially set.
There are some CA that offers Auto-CSR wherein they will generate the CSR for you. This is more secure since the password for they private key will be the combination of the password that you set initially and the password set by the CA.
Here is an example of Auto-CSR: https://www.globalsign.com/support/csr/autocsr_domain_organization.php
Hope this helps!

Is the CSR unique?

I'm creating a webpage to take sensitive customer information and wish this to be on an SSL secured page.
Ive been asked by a CA to provide a CSR.
I was planning to install OpenSSL on a server and create one of these.
Does this mean that the server I create the CSR on will be the same one I have to install the certificate they provide me or can I install it somewhere else?
What links the certificate they provide to the CSR I create?
Thanks for any help.
When a key pair (public and private) is generated, such as with OpenSSL, a CSR is also generated. The CSR is sort of a wrapper that contains your Organization info with the public key.
This is also the part of the pair where the CA will sign upon.
Once you have received the signed certificate (after paying companies like VeriSign, GoDaddy) you should be pairing the signed certificate back together with the initially generated private key and together they work in the app in which you wish to secure content transmission with. E.g. Web servers.
The key pair, and CSR files generated usually CAN BE moved to other hosts/servers. Only in cases where the key pair generation mechanism involves hardware (such as some nCipher devices) will you not be allowed to move to other machine.
It doesn't matter, where the certificate signing request (CSR) is being generated.
Just make sure, you keep the private key. Otherwise the issued certificate will be useless, as it's the key that "links" your CSR to the certificate.

How to verify a binary signed with a self-signed certificate?

We want to add automatic software updates to our application, but our company isn't yet ready to buy a code-signing certificate from a trusted root CA, so we'll be using a self-signed certificate to sign code updates (.exe and .dll) for now.
Question: how to verify a binary signed with a self-signed certificate, without having to install the certificate, using Microsoft's Cryptography API? The .cer file to check against will be bundled with the application. Or is it simpler to use a generic Crypto library?
You can skip the whole X509 thing, after all you don't really need it if you're going to be using your own certificates...
For what you want to do, first you have to generate your RSA private/public key pair. Then you store the public key in your application.
When you have an update, you sign it on your site, by getting the MD5 or SHA-1 or whatever hash you want to use; then you encrypt that hash with the private key. The installed applications fetch the update and the signature (the encrypted hash); when the application gets the binary file, it computes its hash, then decrypts the other one using the public key and compares them. If they're identical then it's a valid update, otherwise you reject it and warn the user or something.
With X509 certificates that are self-signed the mechanism is going to be exactly that, but the public key is going to have a bunch of additional data like the identity of the issuer which will be the same identity of the certificate.
I seem to recall hearing of a way to enable self-signed certs some years ago, back in the Win2k days, but it was very hacky, not at all suitable for public deployment and has probably been "fixed". If you do think about using some other crypto library, or developing your own, take care: it's very hard to distinguish good crypto from bad crypto.