Alexander 'Alfe' Fetke wrote:
> our customers
> will run our application which will be both client and server.
> the used protocols will be IIOP over SSL or plain IIOP (but then
> of course without encryption, so this case is not of interest).
> we are not planning to issue certificates by ourselves or make
> our customers issue anything.
Standard ssl server certificates have exactly the extension needed to open an ssl
connexion.
It doesn't matter if the protocole on it is HTTP or not.
They could be restricted to have only the server usage, but until now all those I
have seen have both ssl server (receives connexion) and ssl client (opens
connexion) usage.
If you ask for an intranet certificate, this frees you of the contraint that the
common name does should be a FQDN in a domain you own.
It's quite reasonnable for you to use a certificate under a public CA, but if the
expense of a certificate under a public CA is too much for your clients, you
might consider searching a non-commercial option for the clients and having an
OOB (out of band) way of checking if the certificate owner is really your client.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
