Why do we need cacert.pem?

Question

I haven't included details about my instrallation because its a "general" question.

I thought the purpose of an SSL server was for the SERVER to present it to the client so the client has faith in the identity of the server.  The client uses its own copy of a CAs public key to verify the signature of the server when the certificate has been signed by a CA.   When its a self signed certificate, I can understand the client having to say I trust the certificate as there is no web of trust.

But I can't understand WHY we need to put the *server* certificate on the client.  Surely the client only needs the public key for the signing authority?   Can anyone explain the logic / reason for that (and I'm sure its quite simple and I'm missing something!)

Thanks

(And thanks for an excellent peice of software ;-) )

Answer 1

Webserver with SSL :
- you need to provide certificate to Apache (if selfsigned, private and public key, if signed by provider, signed certificate and chain).

Client :

- it's possible to communicate with server with or without verification of (public) certificate. (Usually a browser had a list of public authority's certificate, able to verify a signed certificate, and browser goes to stop communication for selfsigned certificate more or less)

- the OCS agent could verify the certificate provide by the webserver with a copy of certificate (=cacert.pem) installed with agent (and with SSL=1 setting).

It is obvious you can get easily the public certificate of a HTTPS server and save it as 'cacert.pem' : so comparison is easy.

If you want register any computer in a OCS server : you get the certificate and save it as 'cacert.pem', and GO you can register (except if OCS server use user/password).

The security is very low (or nothing), due it's easy to get the certificate provided. (I suppose when the ideas was writed, it's was excessive to implement a PKI with a CA, server certificate and agents certificates plus crypt and signed inventories.)

Answer 2

(I've entered this as an answer because I can't "Respond" to Jacquesh's answer!)

Thanks Jacquesh.
Do I understand correctly that, although this is an SSL certificate, the verification is not performed via normal SSL process (as you point out, contacting the CA etc) but is just a case of the OCS client checking its copy of the cacert.pem file against the copy the webserver sends and, if the 2 are the same, it accepts that as proof of identity?

Answer 3

I suppose the process depend of agent's version (and libraries like SSLeay ...).

When you set SSL=1, you have to install with agent a certificate file (CaBundle=xxxx for Windows agent, ca=xxxx for Linux agent). This certificate is a copy of public certificate of OCS web server.

I suppose agent try to connect to OCS server and make a comparison between local certificate file and the certificate of web server.
I'm not sure agent do a check of the certificate of web server as modern browser does ...

Modern browser (Firefox, Chome, ...) are able to check a web server (public) certificate to look if the certificate is signed by an Authority like Amazon, Atos, Affirm Trust, certSIGN, Comodo, ...

OCS Agent don't have this list of Authority, so it can use only the copy of certificate installed to check the (public) certificate of OCS web server.

IMHO this check is very poor due it's a copy (and it's easy to get the certificate of OCS server).

If you want to pollute an OCS server (which use HTTPS), you search for name of OCS server (easy), you get the certificate (easy) and you could create a false hardware, inventory, change the name, inventory, and so ...

I suppose this url https://stackoverflow.com/questions/74358/how-can-i-get-lwp-to-validate-ssl-server-certificates (2008) give a context of this situation : OCS agent (Linux) use perl and LWP + SSLeay librairies ...