Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
I needed to reach a web service which is not mine.
The IT department of that web service has asked me to send them a CSR (certificate signing request). Then, he will send me back a signed certificate which I can include in my calls with PHP by combining that certificate with my private key.
What did the certificate authority do to allow me to do this? How does the webservice now accept my calls? Can someone describe to me step by step what they have done?
A CSR is a file that contains your public key and the data that describes your server -- such as its hostname ("common name"),etc. A certificate authority (CA) is an intermediary that you and the parties you connect to mutually trust. A CA will review the CSR you submit and then issue a certificate, which is usually the same data as in the CSR plus CA's own digital signature. When you offer this certificate to servers you connect to, they check to make sure that the CA signature is valid and belongs to a CA they trust. This simplifies the procedure of assuring trust between parties by placing it into a "mutually trusted authority."
I suggest you search for terms like "what is a certificate signing request" and read some introductory articles on x509 public key infrastructure.
A certificate is an object which contains a name and a public key, and which is signed. The certificate authority is the entity who applies the signature: by doing so, the CA states: "this public key is really owned by the guy with that name". Key ownership is defined by control of the corresponding private key.
The certificate request is an object which contains a name and a public key, which you send to a CA. The CA will build the certificate (and then sign it), putting in it the relevant data; in particular, it will put the public key which you sent as part of the request. Of course, the CA will do so only after verifying that it really is your key (I surmise, or at least strongly hope, that, in your situation, the "IT department" has a reasonably reliable way to make sure that the certificate request they received is really the one you sent). Of course, to produce the certificate request, you had to generate a public/private key pair. The private key never left your computer; only the public part was sent to the CA.
By installing the certificate in your machine, right along the corresponding private key, you allowed PHP to do certificate-based client authentication. The main protocol for that is SSL/TLS (thus HTTPS, which is HTTP-over-SSL). When the SSL client connects to the server, they do some cryptography (the "handshake"), and the server may then request a certificate from the client: the client must then send the certificate and use the corresponding private key to answer a challenge from the server (basically, computing a digital signature). The server then validates the certificate (i.e. verifies the signature which the CA applied on it): this certificate tells the server what is your public key, at which point the server can verify your answer to the challenge and, therefore, make sure that it is really talking to you.
Summary: the server authenticates your client by verifying that the client controls a private key which corresponds to a specific public key. The certificate binds that public key to your name. The CA establishes this binding. To produce the certificate, the CA needs to know your public key; your public key is contained in the certificate request that you sent to the CA.
