I am a software developer but a newbie when it comes to online security.
Company A has some desktop software used by customers C and D (C unrelated to D).
Company B has a web service and has the same C & D customers.
C & D need A's software to connect to B's web service and import their specific data.
A contacts B and asks what is required to achieve this and is told to do the following:-
1) Create a private key
- openssl genrsa -aes256 -out chosencertificatename.key.pem 2048
- (add a password when prompted)
2) Create a CSR
- openssl req -key chosencertificatename.pem -new -sha256 -out chosencertificatename.csr.pem - (enter relevant information for certificate)
3) Send the CSR to B and get a certificate back
- You will be issued with a valid certificate for accessing the APIs.
- The certificate chain used to sign the request will also be issued.
4) Associate with you private key using a PKCS12 file
- openssl pkcs12 -export -out your_pkcs12_file.p12 -inkey your_private_key_store.pem -in certificate_sent_from_nucleus.pem
5) Use in your application
- Embed the certificate in your application
- Each request must contain the Client (X509?) certificate - Each request must also contain an X-USERNAME header to identify the customer
(C and D will be given their own username tokens - plaintext ID?)
I am not sure this seems secure since it seems to me that the certificate can only identify that A's software generated the request; the X-Header seems to just identify whose data to return - if C finds out D's X-USERNAME then they can access D's data which seems even less secure than userID/password.
Also, is it safe to pass around a certificate that has a private key embedded in it?
Rereading the instructions sent by B, it appears that A also needs to inform B which customers require access, the reason being that B can write to those customers confirming their permission to access data via the API.
Could it be that the certificate returned by B contains an embedded list of the validated X-USERNAMES?