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?

3 Answers 3


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.


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 )

  • You gave a software package to your client and client signs the code. It is not good to sign anything you don't own or not liable for. map it with serial number via your software code and each certificate replacement will lead to software re-deploy (because you have to recompile the software each time). Doesn't sound good either.
    – Crypt32
    Nov 2, 2016 at 18:20
  • What is wrong in this if I don't want anything not signed by me to my setup. In fact it is good practices Nov 3, 2016 at 1:08

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.


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?

  • The article you refer to talks about pinning additionally to the usual PKI and how this might be abused for denial of service. But this is not a problem of pinning by itself, only by the way pinning and PKI are combined with HPKP in the browsers. The main problem with using pinning instead of PKI is scalability of trust. But this is less a concern if you have to distribute an application to the customer anyway and thus can include the necessary trust information together with the application, i.e. pinning without PKI. Nov 1, 2016 at 20:45
  • Although, the article is not directly related, it describes some actual issues with pinning. Pinning by itself (without PKI) is worse than PKI because (as you mentioned) of scalability. When you have two clients, this may work, you can ensure that all clients run the same version of the software (this is a requirement too!). But when the list is increased to 5+, most likely the system will break, because will be unmaintainable. I've seen such unlucky cases. This is why I dislike pinning as a tool.
    – Crypt32
    Nov 1, 2016 at 20:52
  • Scalability of trust is only a problem if multiple certificate are involved. If you have just a single certificate to authenticate the server and include this certificate in the application as the only trusted one there is no need to scale as long as you keep the ability to update the application. Nov 1, 2016 at 20:58
  • As per OP I see that multiple certificates are involved in the process as clients authenticate themselves to server.
    – Crypt32
    Nov 1, 2016 at 21:00
  • 1
    My understanding of the user case in the question is that each client effectively ships its own (signed) application which only communicates with the clients server. And from the view of the client there is only a single certificate then. But I agree that it feels bad to reuse the code signing certificate for the server. But it is also a hassle to maintain two certificates: one for signing and one for the server. Nov 1, 2016 at 21:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .