Suppose I have a server provide a POST URL to send CSR. The response certificate then will be used for later SSL client-cert auth connection.
The problem is anyone can POST a CSR to the server and then the server just sign it. Isn't this procedure meaningless?
My colleague suggest the sending CSR itself should also be SSL client-cert auth connection. He will generate a one-time certificate for client to pre-install and use it to do send CSR. Is it a good approach?
I guess you want to enroll users by POSTing CSRs. There is already enrollment schemes builtin browsers so you dont have to POST CSR's. Those enrollment schemes will also automatically install the client certificate in the browser store, so Everything is done in one shot.
Here you have Everything to get started: https://stackoverflow.com/questions/9197484/generating-client-side-certificates-in-browser-and-signing-on-server/9198400
This should take care of Everything. Now, your only problem is authenticating users as users Before enrolling them.
I guess this is the problem you want to solve, in other Words, authenticating users so not anyone can enroll themselves, eg only specific invited indivuals should get a account.
If you can provision software to the client computers via some administration suite, you could provision a "RunOnce" that contains a url like http://www.example.com/CSREnroll.cgi?key=sgdghdghdkgkdsgfketgebgkebekgbksdhfbkgbavbkajvbebkjgbtkekagb where key= is a securely generated, random one-time key, that allows enrollment of one certificate. Since your provision software will propably be able to know the client's IP, you could also lock the key= to only be valid to the IP in question, thus gaining extra security so if this one-time key would leak out prior to its usage, it would be impossible to use it.
If you dont have any administration suite and no possibility to identify users today, I would suggest manual enrollment. This can be done by setting up a password protected enroll page that only you as a administrator know the password of, and then you physically visit each user and enroll them.
Installing a one-time certificate is a unneccessary step, since you would still have to verify the users prior to installing the one-time certificate. And if you have verified the users as authorized, then you dont need to take the step of installing a one-time certificate.
If the users are located not so near, you need to establish Another way to verify the users. Lets say the users need to call the "Helpdesk" to get a account, and verify themselves with a customer representative. Then you could make a page where they have to enter a 8 digit "enrollment ID" that you give to them over the phone after successful verify. This enrollment ID could have a validity of about 5 minutes giving maximal security. You could even have a challenge that they have to read to you, you enter all details that should be written in certificate, they get a response, and they have to type the response to get their cert enrolled.
It depends what you want to achieve.
If you only want to identify a customer for her next visits without knowing anything more from her, that is enough, provided the certificate is retrieved in the same session that have posted the CSR - you should ensure that the certificate is destroyed if the session ends before it has been downloaded. But either use a private PKI or advertise that your certificates control neither the name nor the email or organization of the recipients.
If you want to only be able to certify that the owner of the certificate is the owner of a mail address, just send it to that mail address. But again advertise that you have not verified the identity of the recipient.
If you are just signing server certificate requests, and already have a way to securely identify the security officer of a customer company on your server, just proceed. You can trust that the CSR has been posted by the security officer and that only him should be able to retreive the certificate
But if you want the certificate to be used for general purpose and certify the identity of a person, you must find a way to control that the person that receives the certificate is who she claims to be. For serious organizations, it means that a member of the Certification Authorities actually sees the person to whom he gives the certificate and ask her to prove her identity with an official document like a driving license, a passport or a national identity card. Here a web or mail delivery is simply not possible...
