Signing API requests with a private key: Does this key delivery scenario sound secure?

Question

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?

Edit: 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?

Answer 1

if C finds out D's X-USERNAME then they can access D's data which seems even less secure than userID/password.

Can they? B might generate a separate certificate for each customer which can only be used to access their data. The X-Username header might simply be metadata. But you might want to try this out to be sure. Especially when they don't ask for which customer they are supposed to sign the certificate.

Answer 2

Company A as a software provider will need to make sure either:

With embedded certificate:

• A sends a separate CSR to B with a different key for each customer C and D.
• A embeds the respective private key into the executable before delivery to either C or D. This exposes the private key during delivery.

With no supplied certificate (alternative solution)

• The customer itself files a CSR with it's generated key to B
• A just delivers the software without a key but the requirement to import a key before use.

Either way, the private key should never travel to B. This is not a requirement - just the public key must be signed. The alternative solution is more robust with many clients and takes a way the risk of key leakage from Company A.

Answer 3

Do not even try to authenticate applications, just authenticate users! And if you want serious PKI management procedures, a private key should always be under exclusive control of its owner: it is a key requirement for non repudiation. If A builds the CSR and after B signing them gives them to C and D, an admin from A company could keep a copy of the private keys and later do any operation on behalf of C and D.

Forced usage of software from A company should be cared at legal level, not at technical one. Only C and D authentication should be guaranteed by certificates.

And if you think that your security requirements allow A company to create the private keys for C and D, then my understanding is that you only need password authentication and PKI usage is just overkill and adds no additional security.

---

The following is no more than my own opinion of what a possible way could be. First, creating a full certificate on A (including the private key) and sending it as a PKCS12 file to C and D is definitely bad practice and should be avoided. But as A provides a desktop software to its customers, the generation of the certificate could be included in the installation procedure:

• the installation procedure generates a key pair (automatically, with the help of OpenSSL library)
• it asks the customer for an ID (for example a license number), a name and includes them in a CSR
• the CSR is sent to A (with HTTPS), automatically signed by A after the ID has been controlled and the certificate (without the key) is stored by A indexed by the ID. If an old certificate was associated with that ID it is revoked (depending on your business requirement, this part could require a manual procedure...)
• the certificate signed by A is returned to the installation procedure
• the installation procedure stores the certificate in the system store (assuming Windows here) - the user is normally required to validate the UAC

Once this is done, the client has a certificate signed by A and the key has never left the client machine

On another side, A provides B with its own signing certificate (not the key!), and a certificate revocation list address or any other way to control whether a cert has been revoked

When a customer wants to use the web service from B with A software, it can authenticate its HTTPS connection with his certificate - A software knows how to use it because it has been installed by the installation procedure. B can validate the certificate with A's one, and can even control that the certificate has not been revoked.

The separation of responsability is:

• A is responsable for the PKI: signing customer certificates, maintaining a CRL and the list of the customers
• B is reponsable for its web service. They relies on A for the security of certificates (link certificate <-> customer)
• C&D are responsable for the security of their private key. They should be able to ask a new certificate if it is compromised of lost by restarting (part of) the installation procedure. In that case, the previous one should feed the CRL

As only automatic procedures are involved in certificate generation we are still far from true non repudation requirements, and the installation program will require some work but:

• this relies on standard X509 certificates procedures and protocols
• the responsabilities or A, B and C&D are clear