If you are trying to 'consume' external webservice in RoD environment, then there are always challenges of network connectivity and accesses. Only BMC can help you to open required ports and add required certificates.
I believe it's just the opposite from my understanding of the architecture. Web services provide an architecture to build an application over bog standard web protocols - e.g. http and https (OSI layer 7). That doesn't limit the ports (since that's transport). Since SOAP is between those two I'm guessing presentation layer, but that's neither transport or protocol dependant? Weak on that bit.
Long story short, since it's HTTP/S - anything anywhere can connect to web services the same way web browsers can connect to Mid Tier.
As for certs, yes BMC would have to install them. I'd still need to purchase them. Or provide them. I'd rather provide them than purchase them.
The issue with a cert that isn't purchased is there's no "Certificate Authority." A certificate authority is a well-known (trusted) certificate provider, and their signed certificates will (usually) come pre-loaded into your operating system.
You may have seen errors on occasion that a certificate is unsigned and you have to add an exception in your browser. This is always the case with self-signed certificates (well you can make a CA as well, but it would have to be on every single browser or application (like a web service) that accesses your web server, if it want to connect via HTTPS.
Hence the question. If something connecting to the web service is expecting a signed CA, it won't be able to authenticate since there's no one there to manually add an exception. I suspect when you write the application you can specify in the program to allow unsigned certificates. But I'm not sure. Hence the question.
I'm just guessing, but surely other admins have used self-signed certs with Remedy Web Services.
I think it should be okay since I'm fairly convinced that will just need to be taken into account when writing an application.
I'll let you know when I know.
BMC support said there should be no problem using self-signed certs for web services over https.
That's fine but are they going to provide and configure it?
Yes - they have to configure since we're on demand, I don't have access.
That word document is a bit outdated I think - it's from 2007 and only references the old administrator tool. I might have a poke around for an up-to-date version, it's quite interesting.
But it turns out that's not the case!
After doing a bit of research it won't work, with no a trusted CA on the machine the app will need to be able to download the client certificate somehow, but would error because that's what happens when there's no CA installed on the machine. In some cases you can code your web app to get around that, but definitely not possible if it's a java application.
I do not understand why you need a self signed certificate when you already have a midtier accepting https connections? I do not know RoD environments though.
If you can connect to your midtier via https then you could save the certificate from your browser and then import that into the certificate store of the java application which is consuming your webservices (this is explained in the obtaining ssl certificate section of the document provided by Ganesh Gore).
That document is very out of date.
The connection to Web Services is to the plugin server rather than midtier. The plugin server is java therefore an SSL certificate is needed in the Java keystore.
If one consumes webservices your ar server provides then the connection is made to the midtier. If you consume a webservice from an external provider then the java plugin makes the connection.
You mentioned midtier in initial post so I assumed that someone is consuming a webservice your ar server provides.
Yes, for the most part it will be someone else consuming our web services.
I'm not understanding the data flow at all here. Thanks to Wikipedia I'm more familiar with the term Service Requester than Service Consumer so I'll use that for now, please correct where I need to be corrected.
The easy bit is:
So...what your saying is:
Service requester (consumer?) connects via MidTier to the Service Broker which is behind Mid tier; then the Service Provider (AR Server) validates the Service Request then the Service Requester connects via the Mid tier to the AR Server which provides data back to the Service Requester via Mid Tier, and on until the Service Requester gets all the data it needs and ends the session...
Is that correct?
So currently the web service URL for service context is http://server.onbmc.com:0000/arsys/services/servicecontext_attr_itsm?wsdl
Who is the client of that connection and who is the server, and where would the certificate need to be to enable SSL or does the URL just need to be changed to HTTPS?
I'm not an expert on webservice archtecture but I think in this diagram the service broker would be the atrium core webservice registry if you have this installed.
I think you only have the service requester (eg. soapui on your local workstation) and the service provider (the webservice on the ar server provided via midtier).
Okay that makes some sense.
There is a UDDI URL configured in the AR System administration console and that is indeed HTTPS, so far so good. So in theory the WSDL and / or end point URL(s) would only need to be HTTPS rather than HTTP and it should just work.
The service requesters will be other web applications wanting to create incidents, and whatever it is in Remedy that makes service context work.
Now to figure out how to stop HTTP from working as well....
If you have access to the tomcat configuration you can configure tomcat to redirect all http requests to https (eg. How to configure Tomcat to always require HTTPS | ITworld ) or disable the http connector at all.