Recently I tried to implement a Web Service which resided on an https server, but it just wouldn't work. I kept on getting a HTTP 407 error code (Proxy authentication required). I must admit that I couldn't work out what the problem was since neither end uses proxies.
The WS-WSDL was perfectly callable from any browser, and consumable via Altova XML Spy. On top of that, if I tried browsing to it in the WebAS (see also Craig's SDN Meets Labs: Integrated Web Content and my article), I got a server 500, which was even worse. I called the security guys, since all our SAP machinery is secured tightly network wise, in order to check whether some firewall was to blame for this. The problem wasn't there either.
SDN
Then I had a look at SDN. I found Thomas' web log on Calling WebServices from ABAP via HTTPS . However for some reason I didn't see the link with ‘my' problem. You see Your Honour there were attenuating circumstances to account for this:
• there was the stress of the deadline breathing down my neck
• if everything is perfectly retrievable via a browser, why not WebAS?
• I was blinded by the HTTP 407 and 500 error codes
• I asked Craig if he had also had the same problem retrieving HTTPS URLs. His confirmation lead me to suppose that it wasn't a local problem and that it had to be found elsewhere
• I didn't want to bother Thomas for this based on the above reason. After all, Kimball has his own certificate server, which we don't have in my case
• my reluctance for experimenting was based on previous bad experiences with wildcard certificates
• I'm a stubborn old man, with too many fast and furiously disintegrating little grey cells which make me (feel) stupid.
Plenty of arguments as you can see, but are they justified? Not at all, but all this made me search for help from OSS. Guess what they came up with? Yes indeed, exactly the same note and solution as Thomas mentioned. Check the web log for further details on that.
Bulk
Besides the above method, they also provided a method of importing CA certs in bulk. In order to prevent you from making the same mistake as I, let me share this:
- download the SAP Cryptographic Software for Windows on to your local machine
- create a new PSE with a (dummy) keypair and self-signed cert:
SAPGENPSE gen_pse -p %TEMP%SAPSSLA.pse -x "" -noreq CN=anonymous - populate the list of trusted CA certs of Microsoft Internet Explorer:
SAPGENPSE maintain_pk -p %TEMP%SAPSSLA.pse -y –M - upload and insert the resulting SAPSSLA.pse file with STRUST
It could be that you need the import additional CA certs the manual way, due to not available in the MIE list.
Problems with SDN
A point of attention is a possible issue with SDN, even after implementing the above. The 'problem' occurs when you try to crawl https://sdn.sap.com
As you can see within your browser, it is redirected to https://www.sdn.sap.com which is the real URL that has been certified.
The WebAS compares the URL of the cert with the one you try to retrieve and finds a difference and considers this as security problem.
The solution to this is to use the URL of the cert, meaning https://www.sdn.sap.com .
Conclusion
It's all rather obvious don't you think? Don't always think that your problem is specific to you, even if the symptoms look (somewhat) different. Look at the problem without blinkers, be open minded and don't be afraid to ask people for help. The whole SDN forum philosophy is based on this.
I lost a lot of time by failing to do this. Isn't it stupid, me trying to be an SDN evangelist preaching the benefits of SDN whilst sinning myself. I've learnt Web Services: The Case of the Missing SOAP Action Header well.
6 Comments
