Is it possible to forward a X509 certificate?

I'm working on a system that has a basic client-server architecture that also integrates with a 3rd party via Web services that are called from the server. The 3rd party currently does authorization via X509 certificates and wants to continue to do so. If the 3rd party's certificates are installed on the client and are passed each time the client communicates with the server, could the certificates be forwarded along to any calls to the 3rd party's Web services? Is this even possible, or is it contrary to what certificates are designed开发者_如何学运维 for?

First, you need to understand the difference between certificate and private key. Often, people say they sign something with a certificate, whereas they actually sign using the private key corresponding to that certificate (which contains the public key and identity-related information) and present the certificate to the remote party. You (should) never let your private key out.

Verifying the signature of a document (or of the TLS CertificateVerify handshake message if you're using TLS client-certificate authentication) guarantees that the signer has the private key corresponding to the public key in the certificate you're given within the handshake.

Validating and verifying the certificate is about checking you trust the information bound to that public key in the certificate. This assertion is usually made by a 3rd party you trust, a Certification Authority (CA).

In traditional PKI (RFC 3280 or RFC 5280), certificates also have extensions (alongside the identity information) to describe the purpose for which the CA has issued that certificate. CA certificates themselves have an extension to say that they are CA certificates (there are multiple conditions to fulfil, in fact). In this model, an end-entity certificate (which isn't a CA certificate, but was issued by a CA) is not allowed to issue other certificates, which could be used to delegate its identity (and/or authorization to perform certain actions).

The Proxy Certificate Profile (RFC 3820) was designed to work around this. In this context, even an end-entity certificate can be the issuer of a proxy certificate, which must contain specific attributes. Especially, since a new public/private key pair is generated for this, and since the private key is often not protected by the end-user but by the service delegating the usage of the certificate, proxy certificates must be short-lived (hours instead of years). This work comes from the Grid Security Infrastructure (GSI).

This is usually not supported by default, so you may need to change the configuration of the parties using this. Support also depends on the language you're using.