One of our customers wants to receive data from us via https but only has a Self Signed Certificate and not a CA. The customer doesn’t want to incur the expense of the CA unless absolutely necessary. How can I configure my server to send them an HTTPS file without thier CA Certificate?

Thanks,

Kevin

You should enforce the security policies established by your company. While you could make the argument that a CA-signed cert is not needed for development or testing environments, I would suggest that you not do so for production.

The purpose of the cert is to confirm the identity of the client. If you are OK with the general public consuming the service you are providing then configure your HTTPS port to perform only basic authentication. If you are going to require certs then it makes sense to require real ones and not self-signed ones that can be created by anyone with an OpenSSL toolkit.

You can purchase CA-signed certs for under $50 from suppliers like GoDaddy. Surely, that kind of cost is not an obstacle for a production system.

At any rate, its your call as the service provider. You are only one who is capable of securing your system adequately. Your clients and partners don’t have (much of) a say in your security.

I’m not as concerned with the public having access to this service since we’re pushing all the data to them and our firewall is only open to specific partners. Whenever I attempt to do the send via https I’m getting the SSL Chain Verifier Error. I guess what I’m trying to ask is there a way to post documents to a customer without them having to get a CA Cert. If so how do I do it to avoid the SSL Chain Verifier Error in webMethods?

Thanks,

Kevin

Kevin,
Adding your client’s true self certificate to your trusted CA directory would do the trick.
~tS

Mark,

Certificate signed by a signing authority might be really helpful if we have a website that is accessed over internet by public users - where it may be considered as trusted source if your cert is signed by a well known authority. However when we trade with a partner company - even with self signed certificate we go through approvals and procedures to on-board the partner and to install their self signed certificate in the system.

I have even seen bigger VAN’s using self signed certificate.

Do you see any other potential risk in using self signed certificate for any such company-to-company trading.

Thanks,
Maasil

Just summarizing my thoughts on the ‘non-standard’ CA issue:

• The SSL protocol requires the server to possess a certificate.
• The SSL client (the one that initiates the connection) must ‘trust’ this certificate (i.e. it must ‘trust’ CA that issued it)
• Some folks choose to sign their own SSL certificates, instead of paying Thawte or Verisign for the privilege
• The client must then ‘trust’ these ‘non-standard’ CAs. (see note below on this term)
• If a hacker steals the private key of that non-standard CA, this can help ‘impersonating’ the server to the client. However, this must be done in conjunction with hijacking the ISP, DNS spoofing or man-in-the-middle (MITM) attacks. i.e. its non-trivial.
• In any case, the hacker can buy a regular Verisign SSL certificate and install it on the server used in the MITM attack. As long as the webMethods client trusts the Verisign CA, this would still work.

Hence (and its possible I’m wrong), this conclusion: configuring a webMethods IS instance to trust a non-standard CA doesn’t reduce the security of IS in any material way

Note: I choose to use the term ‘non-standard’ CA instead of ‘self-signed’ because all root CAs are self-signed anyway. My rule of thumb for ‘non-standard’ is a CA who’s not trusted by the top 4-5 browser vendors.

Thanks Rob!

Two more minor points regarding ‘non-standard’ CAs and SSL connections.

When an SSL client connects to a webMethods IS SSL port, IS returns a list of trusted CA authorities to the client. You can view this by running this OpenSSL test client command:

openssl s_client -host <IS> -port <IS_SSL_PORT>

(See output under “Acceptable client certificate CA names…”)

Perhaps this information is only required when client certificate authentication is supported by the server. Connecting to GOOGLE.COM via SSL, for instance, does not return the list of CAs, but connecting to SDN.SAP.COM (which uses client certificates) does return a small list of acceptable client CAs.

I see two issues with this behavior and ‘non-standard’ CAs:

• As the list of trusted CAs keeps growing, SSL connection setup overhead increases slightly. (Usually, this is too minor to be an issue)
  
• [i]However, an SSL client may obtain information on third-party business relationships of the company running the SSL server [/i] (because the third-party self-signed CAs are returned to the client.)

Hi All,

Can anyone answer to Kevin’s question. With possible options to ignore or bypass self signed certificates while sending request using Https client.

Thanks.

Hi,

as from wM 8.x onwards there is “Trusted CA Directory” in IS.

You should import all CA-certificates as well as all those self-signed certificates into a Java-KeyStore (JKS) file and configure this one as a truststore in IS.

They keystore file can be build using keytool, which is part of every jvm distribution:
keytool -importcert -trustcacerts -keystore your-keystore.jks -file yourcert.cer -alias youralias

You can add multiple certs to this jks-file.

See IS Administrators Guide for further informations about this.

Regards,
Holger

discussed in another thread, you can set:
watt.security.cert.wmChainVerifier.trustByDefault=true