Can I use a code signing certificate as a TLS certificate?

Question

For example, I develop a software which is used by some customers. They sign the software using their code signing certificates. The software has a client and a server part which are connected to each other using TLS.

The client part works on Windows and I can check if the digital signature is correct or not. Then I can extract the name of signer from the certificate (the public part) and use it for some additional verification.

Can I use the code signing certificates for the server part as TLS certificates and verify the signer name instead of FQDN? I understand it is not typical. Is it secure? For instance, can different company code signing certificates have same CN (the name of signer)? What additional problems might I have here?

Answer 1

If you have full control of the client you can of course setup your own validation routines and ignore the existing ones. In fact you could just reduce the checks to the validation of the public key of the certificate (i.e. pinning). But it is recommended to stick with existing and proven designs and not to reinvent your own validation since these are critical things and easy to mess up.

Still, considering that you nonetheless want to use the normal validation process as far as possible and only tune it when necessary there might be more obstacles than just that the subject which does not match the target host name: A certificate has different key usages. For code signing you only need the ability to sign something. But for use with TLS you might also need the ability to use the certificate for keyEncipherment, a feature which is not needed for code signing and which might therefore not be as allowed usage of the certificate. Also, TLS server certificates usually have an extended Key Usage which explicitly allows the use for server authentication while code signing certificates don't need this.

Another problem is that by reusing the code signing certificate for the server you probably expose it more to attacks. Theft of code signing certificates and use of these trusted certificates to sign malware is actually not uncommon and having the private key for this certificate on a host which is maybe exposed on the internet just sounds like a bad idea considering how often such hosts gets hacked.

Answer 2

From my understanding of your problem domain , i think there is not much to discuss

• You gave a software package to your client
• client having a code signing certificate , client signs the code ( both parts client part(CL) and server part (SR))
• Client install the client part on his client machine (CLM) as it is signed by Trusted CA ( i assume ) CLM OS will trust it and will get installed
• similarly the SR will be installed on the SRM i.e.. server machine

so far so good the code signing part of the certificate is over as of now , so lets move to your second problem

Can I use the code signing certificates for the server part as TLS certificates

As @steffen pointed out about the extension KEY USAGE

For your setup to work with standard libraries of cryptography you will be needing two key usage extensions for your setup

Key Encipherment :

required at server end so that client will send keying material to server secretly

Digital Signature:

• Required by the server to prove its identity ( entity authentication)

• Required for code signing

If these extensions are present that you can use the certificate for Code signing and for tls handshake server side certificate

else if these extensions are not present then too , there is no harm in using the same certificate for TLS as far as you are keeping your private key secure by keeping your machine secure . Cryptographically this is no way to say that it is insecure to use .

verify the signer name instead of FQDN

This is also up to you how accurately you map the entity and its associated proof , that is also very simple to achieve in your case , as you need to map code author identify ( map it with serial number via your software code )

Answer 3

There are a lot of serious problems with your design. I would not proceed any further in this direction, instead I would go with standard SSL/TLS communication with appropriate certificates to perform communication encryption and authentication.

Few things that are bad in your design:

1) Code signing certificates are intended for code signing. An attempt to misuse the certificate breaks entire PKI.

2) I develop a software which is used by some customers. They sign the software using their code signing certificates -- this is the wrong way. Clients SHALL NOT sign anything they don't own. Once they sign, they will become liable for anything they actually didn't do. It is your software and you are responsible for it. You can approve your responsibility/liability by signing binaries, but your customers are not liable. Under certain circumstances this may raise legal issues.

3)

For instance, can different company code signing certificates have same CN (the name of signer)?

actually, yes. Two companies may have identical CN attributes in code signing certificates (though, entire Subject field will not match). This may happen when certificates are issued to individuals and it is not uncommon when individuals have the same first and last name. But the rest attributes (as said) will differ.

In addition, you will have to develop your own validation procedure from scratch, as the result it may be quickly vulnerable. Do not try to reinvent the wheel when there are well-tested and proven standards to use. Certificate pinning sounds like a good idea until you face certificate management. With certificate pinning there are a lot of problems with certificate management and one of the reason why this technique is not very widely used in internet. This article is worth reading: Is HTTP Public Key Pinning Dead?