I have small doubt regarding the process of X509. I am aware of OpenPGP Encryption/Decryption, where we generate the public key and private key. We can share the public key to vendors and they can encrypt data with the key and we can decrypt the data using out private key. It's simple and straight-forward for me.

When it comes to X509, I am bit confused. My client wants to use X509 certificate to transfer sensitive information [which's already encrypted using symmetric Encryption like AES] between two people [between client and his vendors]. How X509 works if we can generate the certificate using only public key.

Assume, if I encrypt the data using AES with one random generated key. How do I transfer this data along with key to vendor using X509 so that any third party will not intercept during network transmission.

Could any one please explain? Btw, we transfer the data in SOAP message including Certificate info

  • 2
    A minor note, but AES is a symmetric algorithm, because the same key is used for encryption and decryption. Public key algorithms such as RSA are asymmetric because two different keys are used.
    – lynks
    Feb 19, 2013 at 14:32

2 Answers 2


X.509 is a format for certificates: a certificate is a sequence of bytes which contains, in a specific format, a name and a public key, over which a digital signature is computed and embedded in the certificate. The signer is a Certification Authority which asserts that the public key is indeed owned by the entity known under that name. By verifying the signature, you can make sure that the certificate is genuine, i.e. is really what the CA issued; and, that way, you gain trust in the binding of name with public key (insofar as you trust the CA for being honest and not too gullible, and as you know the CA key for signature verification, which may entail obtaining a certificate for the CA, and verifying that certificate, and so on, up to a trust anchor aka root certificate).

Thus, X.509 is a way to distribute public keys, by which I mean: a method which allows various actors (e.g. you) to know, with some guarantee of non alteration by malicious third parties (i.e. "attackers") the public keys of other actors.

OpenPGP is a standard format for a lot of things. One of the things which OpenPGP defines is a way to encode a public key along with a "name" (an email address), and a signature over these two. That's, really, a certificate in its own right (although with a format which is not compatible with X.509). But OpenPGP also defines how to use the public key of a given individual (let's call him Butch) in order to encrypt a bunch of bytes that only Butch, using his private key, will be able to decrypt. Technically, this uses a randomly generated session key, used with AES (or similar) to encrypt the raw data, and that session key is what is encrypted with the recipient's public key (generally of type RSA or ElGamal).

Therefore, for your problem, you do not want to "encrypt with X.509". X.509 defines nothing about encryption. What you want is to use a standard format which describes encryption with the recipient's public key and builds on X.509 certificates for the public key distribution. This standard format, coupled with X.509, would be an analogous to OpenPGP. This standard format exists and is called CMS (formerly known as "PKCS#7"). When CMS objects are sent by email, this becomes another layer of standard, which is called S/MIME.

CMS (or S/MIME) is what you need for asynchronous communication: you prepare a blob, to be sent later on to the recipient, like what you do with OpenPGP. If you can make a synchronous communication (sender and recipient are "online" simultaneously), then you can use SSL/TLS (or its Web counterpart HTTPS). In SSL, the server has a public key, which it sends to the client as an X.509 certificate. The client validates the certificate, then uses the public key contained therein in order to establish a session key with the server, and encrypt the data with that session key.

In any case, assembly of cryptographic algorithms into protocols is known to be hard to do correctly, nigh impossible to test for security, and fraught with perils. So don't imagine that you may build your own mix; you really should rely on an existing standard, like CMS or SSL.


An X509 certificate is a method of exchanging public keys. It sounds like the vendor probably wants you to continue to AES encrypt and then encrypt the AES key with their public key so that you can transmit the AES key without it being susceptible to being intercepted. By far the most common uses of asymmetric (public/private key) cryptography is signing and symmetric key exchange.

My main concern is that you mention you are getting the certificate in a SOAP request which makes me question how the validation is occurring. This step doesn't make a lot of sense to me since if you don't know the certificate in advance (thus it wouldn't be necessary to send it), then I'm not sure how you would validate it is for the appropriate user that should have access to the data and has not been attacked via a man in the middle.

The preferable way would be for the X509 cert to be one you have signed so that your system can know that the certificate is valid and for the user that has sent it. Then, even if a man in the middle was making the request, as long as they don't have the private key for the cert, they would be unable to decrypt the AES key and the data would be useless to them.

You must log in to answer this question.

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