I am trying to setup a proxy configuration on a dev 853 domino server, so I can connect to a dev connections server from an XPage (using java).
It's an SSO environment, and both the domino server and connections server are protected by WebSEAL. I want to make server-side calls in java (using the Apache HTTP Client), so my XPages application can make a call across to the Connections server.
I followed some information I found in Niklas Heidloff's Social Enabler documentation: http://www.openntf.org/Projects/pmt.nsf/DA2F4D351A9F15B28625792D002D1F18/%24file/SocialEnabler111006.pdf
and also in here:
http://www.ibm.com/developerworks/lotus/library/inotes-full/index.html
I setup the proxy like this:
Context: /xsp/proxy/BasicProxy/
URL: https://connectionsserver.acompany.com
Actions: GET,HEAD,POST,DELETE,PUT
Cookies: -List of cookies-
Mime-types: *
Headers: User-Agent,Accept*,Content*,Authorization*,Set-Cookie
When I try the call, it gives me the following error:
2/28/13 12:34 PM: Exception Thrown
javax.servlet.ServletException: com.ibm.jsse2.util.g: No trusted certificate found
at com.ibm.domino.servlets.proxy.BasicProxy.throwServletException(BasicProxy.java:765)
at com.ibm.domino.servlets.proxy.BasicProxy.service(BasicProxy.java:357)..
...
Caused by: javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.g: No trusted certificate found
I thought that passing the cookies across in this way should work (the cookies should work between both the domino-webseal and connections-webseal environments).
The error suggests that I need to import a certificate. I don't have access to the domino server to allow me to import certificates, so before I request that, I wanted to check I wasn't missing something from somewhere else.
Is there something else I am missing? Or any suggestions on doing this a different way?
Thanks,
Pam.
You have to import the certificates if they are not present. That is what the error message is indicating. There is IBM Technote 21588966 describing the necessary steps.
Furthermore (that could become the next showstopper after you sorted out SSL) you have to have a hard look how WebSeal is configured. The challenge here: WebSeal is designed to accommodate any possible backends and it is easy to get it almost working - almost as in: works for direct access via browser but fails on server-2-server or Ajax etc. The super-highly-recommended-ignore-on-your-own-risk setting for Connections/Domino is to use WebSeal's LTPA capabilities and not some ludicrous code injection.
Hth
Related
When logging on to OWA using a browser, receive a 503 error. In the Fiddler trace will see a more detailed response status code:
503 Failed authentication on backend server: Unauthorized
On the Exchange Server, see the following System event log (intermittently):
Event 4 Security-Kerberos
The Kerberos client received a KRB_APP_ERR_MODIFIED error from the server exchangeserver$.
The target name used was HTTP/exchangeserver.ad.root.
This indicates that the target server failed to decrypt the ticket provided by the client.
I hope someone only receives this in a lab environment!
Here is a link to enable Kerberos logging, which could be helpful as well: https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/enable-kerberos-event-logging
After enabling Kerberos logging, would see the KRB_APP_ERR_MODIFIED error more frequently, whereas before would not be logged each time a logon attempt occurred.
The issue here (in the lab) was that a duplicate SPN for the Exchange Server in question was added erroneously to another server, causing a duplicate. This was due to trying to enable Kerberos delegation for a separate web application.
Although there could be a quicker way to do this, you can list the SPNs on each server to look for your erroneous exchangeserver record by running
setspn -l otherservername (this is a lower-case L)
And if you find that SPNs like http/exchangeserver or http/exchangeserver.ad.root are listed on another server (say 'otherservername'), you can carefully remove them by running
setspn -D http/exchangeserver otherservername
setspn -D http/exchangeserver.ad.root otherservername
I was able to logon to OWA immediately after the duplicate SPN was removed, without restarting any servers or services.
Check, if the bindings for Exchange Backend website in IIS is correctly configured. You can check this by visiting IIS console in the server and open bindings for Backend website for 443 port. See, if the certificate is assigned well
Also, check, if the Default website's binding is correct. It should have thirdparty SSL certificate assigned or the self signed certificate
If any of the bindings are incorrect, fix it and restart IIS (iisrest from cmd prompt). Check again
Short story
I'm trying to send a POST request from a PL/SQL script using the utl_http utility in Oracle. I've been able to send the request using http, but not https. I've added what I thought was the necessary certificates to a Oracle Wallet, and I believe they are being imported and used (but in all honesty, this is a little hard to verify). My current assumption is that calls from our DB server are passing through a proxy server, and that that is somehow messing up some part of the https / certificate functionality.
Supporting evidence (possibly?): I tried to make calls (POST requests) to a dummy service at webhook.site. Again, I got this working with http, but not https - the latter results in a cert validation error.
I then tried to replicate the behavior using postman, and that basically produces the same result, unless I fiddle around with the settings:
Initial Postman result:
Could not get any response
There was an error connecting to https://webhook.site/950...
Disabling SSL verification
Under the Post man settings, I turned off SSL Certificate Verification, and tried again. This time, I got a 200 OK response, and confirmed that the webhook received the post request fine.
It seems clear that the error is due to a missing cert, but I can't figure out which, or how to configure it. My assumption is that if I can get this to work for a webhook-url from Postman (without disabling cert verification), then I should also be able to get it to work from PL/SQL later.
When I look at the webhook site in a browser and inspect the certs, the webhook cert is the lowest cert (leaf node?). Above it there is one intermediate cert related to the company I'm working for, and then a root cert also related to the company. The root node is named something like "Company Proxy Server CA" - So I'm assuming the proxy somehow manipulates my requests and inserts it's own cert here.
I've tried downloading all of these certs and importing them into my cert store, as well as importing them under the Postman settings (under Certificates) in various combinations, but nothing seems to make any difference; all attempts at posting with HTTPS produces the following error in my Postman Console:
POST https://webhook.site/9505...
Error: unable to verify the first certificate
Any ideas about how to resolve this, or at least obtain more information about what to do would be greatly appreciated.
Switching OFF "SSL Certificate Verification" in Postman only means that it (i.e. Postman) will not check the validity of SSL certificates while making a request. Meaning that it will just send the certificates as they are. Because your connection fails if the setting in ON, this means Postman cannot verify the validity of your certificates.
This is most likely the case with the actual service you're trying to POST to, they cannot verify the certificates. Is that service outside your company network? And is it a public one or one owned by your company? Where is that service hosted? What certificate do they need?
BTW, TLS client certificates are sent as part of establishing the SSL connection, not as part of the HTTP request. The TLS handshake (and exchange/validation of client and server certificates) happens before any HTTP message is sent.
I'm thinking this might be a blocked port issue.
You said... ""Company Proxy Server CA" - So I'm assuming the proxy somehow manipulates my requests and inserts it's own cert here."
That means your client software needs your Company Proxy Server CA in its trusted certificates list. If that client's list is that of the oracle wallet...
https://knowledge.digicert.com/solution/SO979.html
This talks about how to do that.
Also, if your system running postman has a non-oracle based wallet trusted certificate (probably the operating system?) you'll have to execute something like adding the trust to your account on the workstation
https://www.thewindowsclub.com/manage-trusted-root-certificates-windows
in order to have the proxy server certificate trusted.
Once the certificate you're making the connection with has a root of trust per the effective configuration of the client being used, then you'll be able to verify the certificate.
A couple of possible issues:
The server doesn't actually support HTTPS. Connect a browser to the URL that you POST to, and see if you receive a response. (It looks like you already did this, but I'm documenting it for completeness.)
The server uses the Server Name Indication (SNI) extension to determine what certificate chain to send back, but your POSTing client doesn't send that extension. You can identify this case by looking up the IP for the host you're POSTing to, then going to https://nnn.nnn.nnn.nnn/ (obviously use the IP here, instead of the literal string 'nnn.nnn.nnn.nnn') in your browser, and checking the certificate chain it returns. If it is not the same as you get from step 1, this is your problem, and you need to figure out how to either get SNI support in your Oracle PL/SQL client or get the POST endpoint exposed on that hostname. (alternatively, you might be able to use these certificates to prime your Oracle Wallet, but they might have an issue with the hostname in the certificate not matching the hostname you connect to.)
You have a proxy in the way. I don't think this is what's going on, since that would basically only cause problems if you were doing client-side certificate authentication. (If this is the problem or is a condition, you need to import those certificates into your trusted wallet; you also need to ensure that the server you're posting from is going through the same proxy. Otherwise, you need to ensure that the certificate authority for the proxy that the machine actually running the code sees is in the wallet. This may require the assistance of the system/network administrators who run that machine and its connection to the network.)
HTTPS is a finicky beast. Many, many things must work exactly correctly for TLS connections to work and the certificates to correctly verify (the TLS port must respond, the client and server must agree to speak the same version of TLS, the client and server must agree to use the same cipher combination, the certificate chain presented by the server must be issued by a CA the client recognizes, and the leaf certificate in that chain must certify the name client requested).
SNI is needed to support multiple names on a single host without messing with the certifications of other names on the same host. Unfortunately, SNI is one of those things that has been standardized for over a decade (RFC 3546), but many enterprise-grade softwares haven't implemented.
I am working with a self-hosted servicestack webservice on a Windows 10 machine and I am trying to enable https on it. What I have done so far is this:
1) I have created a wildcard cert using our companies cert server and exported it with the private key.
2) I have installed the cert on my dev machines' "LocalMachine/Personal" cert store.
3) I have run the following commands from the command line:
netsh http add sslcert ipport=0.0.0.0:{DefaultConfig.DefaultSslPort} certhash={sha1} appid={{{appId}}}
netsh http add urlacl url=https://+:{DefaultConfig.DefaultSslPort}/ user=everyone
4) I added the following to my Program.cs
var listeningOn = $"http://*:{DefaultConfig.DefaultPort}/";
appHost.Start(new[]{ listeningOn, $"https://*:{DefaultConfig.DefaultSslPort}/" });
Now when I launch the project, the http binding works no problem the webservice loads and works as expected. However when I try the https binding, the browser shows that a connection was made and the cert is valid (green lock appears and network traffic shows connection succeeding) however the server responds with:
HTTP Error 503. The service is unavailable.
Clearly it is available (as the Http binding proves) but there is some disconnect between windows and servicestack and I don't really know where to look for answers on this. I have tried a bunch of search phrases but they all seem to tell me to check/do what I have already checked/done or the results are specific to a particular application/framework/OS and have not been helpful.
Ok, so counter to MANY MANY MANY posts out there, you should NOT reserve the url using:
netsh http add urlacl url=https://+:{DefaultConfig.DefaultSslPort}/ user=everyone
When self-hosting with ServiceStack. I don't know why (if you know why, feel free to post a comment) but this makes windows unable to pass the https request down to your self-hosted site. I checked this by downloading ServiceStack source code and put a break point on the connection callback that is the entry point for any incoming connections. The breakpoint is never hit, therefore the request never gets to Servicestack.
Once I removed the URL reservation, everything worked fine.
I am a newbie at play, and I am trying at least to use HTTPS on a login and sign up pages in order to have more security on sensitive user data.
I have a range of questions regarding this:
I have configured my play application to use https on the application.conf file with the https.port property. However in my development environment I cant seem to start the server with https capability unless I use the command: play -Dhttps.port=<port>
Why does this happen? I would think that I could use a dev.conf (right now is the application.conf) file in order to do this. Can't I start the server in dev mode while using this kind of settings specified on the configuration file?
Although I start the server with https capabilities, what is the correct way to use https on play? I already created a java key store that I use, and tried to redirect (from a controller) requests to a https url using redirect(securedIndexCall.absoluteURL(request, secure)). But it does not seem to work at least on my dev enviroment (localhost). The logs specify exceptions like:
java.lang.IllegalArgumentException: empty text
java.lang.IllegalArgumentException: invalid version format: M¥å/=<junk characters continue>
Should I use https on the whole application, or just securing the login and sign up requests is sufficient?
I feel the official documentation provided is rather insufficient and I am at a loss here trying to figure out how I should do this.
Any help would be really appreciated!
I agree with Fernando, I think it's easier to set up a front end web server. In my case I used Lighttpd and it was fairly straightforward to set up. I'd recommend:
Configure Lighttpd as per these instructions (at this stage, don't worry about HTTPS just get HTTP working): http://www.playframework.com/documentation/2.3.x/HTTPServer
Then configure HTTPS in Lighttpd: http://redmine.lighttpd.net/projects/1/wiki/HowToSimpleSSL. If you intend on buying an SSL certificate then there will be a few more options to set (e.g. intermediate certificate). The following page has more information: http://redmine.lighttpd.net/projects/1/wiki/Docs_SSL
Answers to your main questions:
1) Enabling HTTPS in Play
Yes, you have to explicitly say you want to use HTTPS when starting up
http://www.playframework.com/documentation/2.3.x/ConfiguringHttps
2) The "java.lang.IllegalArgumentException" error message
There might be an issue with the keystore. This SO article seems to discuss in more detail: Play framework 2.2.1 HTTPs fails on connection attempt
3) SSL for login page or whole app
Personally, I would go for the whole app. If you're taking the time to set up HTTPS I think you might as well cover the whole site. I guess there are slight performance overheads in running HTTPS but realistically it's not something you'd notice.
You should use a front end server for HTTPS, and use HTTPS for the whole application.
Please see Setting up a front end HTTP server and see the commented out nginx settings.
I am at my wits' end on this one.
FYI, I work in infrastructure, not .net development, so I know very little about WCF and next to nothing about Visual Studio as an environment, but I don't think that's where the problem lies.
We have a WCF service running on a couple of IIS 7.5 servers on our internal network. This is exposed to the outside world via reverse proxy on Apache 2.2.15 on Fedora 11. The reverse proxy handles load balancing between the IIS servers, as well as SSL.
The WCF service is configured to use transport level security, and the IIS servers have self-signed SSL certificates. The reverse proxy does not authenticate the IIS servers, and the only reason we have SSL on the IIS servers in the first place is so the WSDL will present the correct location URL.
We thought we had it working perfectly, but there's one annoying and crucial exception: the WSDL can't be added as a service reference in Visual Studio on machines running Windows Vista or later. On an XP machine, it's fine, but anything later throws the following error:
There was an error downloading
'[URL]'. The operation has timed out
Metadata contains a reference that
cannot be resolved: '[URL]'. An error
occurred while making the HTTP request
to [URL]. This could be due to the
fact that the server certificate is
not configured properly with HTTP.SYS
in the HTTPS case. This could also be
caused by a mismatch of the security
binding between the client and the
server. The underlying connection was
closed: An unexpected error occurred
on a send. Received an unexpected EOF
or 0 bytes from the transport stream.
If the service is defined in the
current solution, try building the
solution and adding the service
reference again.
The WSDL is accessible through a browser, or through regular SOAP, on any machine and without any SSL complaints. It's just Visual Studio that has an issue.
Initial Googling revealed that it might be a problem with the cipher suite that VS used, suggesting that VS on Vista or later would by default attempt to use TLS1.0 in HTTPS connections, and if an intermediary device didn't support that protocol, it would just drop the request. This is definitely not the case, though. The reverse proxy explicitly prefers TLS1.0, and even when viewing the WSDL through a browser, it flags up as using TLS1.0 for the connection.
Having pointed the proxy at other functioning WCF services on different IIS servers, the same error occurs, leading me to assume it revolves around the reverse proxy configuration. The trouble is that it seems to be identically configured to another reverse proxy carrying out the same task elsewhere.
It's presumably some transport level issue around how VS establishes HTTPS connections on different operating systems, but I simply don't know enough about it to hazard a guess about what that might be. Anyone have any suggestions?
Well, that was embarrassing.
I'm sure there's some unwritten cosmic law that results in me finding the incredibly simple solution to a problem I've been grinding away at for days about ten minutes after posting it up on StackOverflow.
The ServerName directive in the virtual host config didn't match the URL. It did match the certificate (which has a Subject Alternative Name, so it didn't throw up any SSL warnings), but that wasn't the name I was accessing it with.
I'm assuming there's some extension of TLS1.0 that VS uses which enforces this, which isn't used by browsers or SOAP clients. This is probably useful information for anyone else trying this with a certificate that has Subject Alternative Names. It wouldn't have come up otherwise.