Hello I'd like to do https calls from my node.js website running under windows azure emulator but I am not sure how to go about enabling ssl using IIS Express ?
Has anybody got any ideas? I've read and tried implementing different ideas but none seem to work for e.g.
https://tootallnate.net/setting-up-free-ssl-on-your-node-server
I am creating a Facebook app which requires me to do some https calls to the graph etc, but IIS Express crashes each time if it encounters warning messages etc and the call never makes it through.
Anyone got a simple self-signed certificate working within emulator that they can share on how they did it?
There's a difference between making outgoing calls using SSL from your service (for example, using facebook) versus accepting incoming ssl calls (for example, from the browser). If you're making outgoing calls, standard node libraries should work and you'll just need a .pem certificate included in your app to use most of them. If you're accepting https calls on the server, then iis (express) takes care of certificates and your server can treat the incoming call as http
Related
I made simple API for which is running on my "server" inside local network. When I want to call api from another PC internet browser inside my intranet over https://xxx.xxx.xxx.xxx:9100/ShowList i get warning from my browser that my connection is not private NET:ERR_CERT_AUTHORITY_INVALID. I can proceed as unsafe but i would like to avoid that. The question is what I have to do to have save connection inside my intranet? I'm totally new in that so i'm aware of thing I have to do.
You just need to add a ssl certificate to the hosting IIS server (assuming you are using IIS as the server). You can create a Self-Signed Certificate, buy from the vendors or use free services. Take a look at
https://learn.microsoft.com/en-us/iis/manage/configuring-security/how-to-set-up-ssl-on-iis
For all docusign developers outthere. I'm using Docusign Connect to check the status of the envelop. I develop a listener that runs on tomcat. The reason why I used this because it's easier to code on my perspective and I want a push type data notification.
It works fine with HTTP, but I spend 2 days now and I still can't get it work for HTTPS.
My question is since the self signed certificate is not working. Do I need to purchase an SSL certificate for my web server?
or Docusign has a work around on this?
On demo sandboxes you can get away with testing without using HTTPS.
On production you will need a server that will actually support error free SSL connections. This means that you will need to wire up your tomcat to use some certificate that validates your website address. Whether it's a new one or just a wild card that you already have - that depends on the situation.
HTH
-mb
I am planning to host a clickonce application in a web server and want to give access over http (NOT httpS). The application is signed with a certificate. I assume that this should be OK not to use https because man-in-the-middle attacks cannot spoof the singed binaries. I've following questions regarding this.
Are there any other security threats that I should be aware of?
Does using http over https increase perceivable performance (assume there are many clients downloading the setup files from server. There should be less overhead on server with plain http)
thanks.
If there is any kind of access control on the application, using http makes it easier for someone to retrieve the application from a network trace, or find out the real URL.
(I use this sometimes when i'm interested in an .apk file. There's no easy way to get the .apk in google play, but when i start a network trace on my router, then have my android install the apk, i can get the URL from the trace and download the same URL to my PC. No rootkits or special software required).
If you have a recent CPU and software stack, then the crypto part of https is done in hardware in the CPU, which means there is little or no detectable overhead in https.
I've been playing with the twitter API for an iPhone test application, and I've missed the ability to proxy the requests I did to the twitter API with a software like Charles (http://www.charlesproxy.com/). Even though it has a SSL Proxying feature, twitter seems to not like the fact that there's a different certificate in the middle signing the requests.
Is there any way to do this? I'd be very useful to be able to see the requests and the way Charles formats the JSON responses, etc...
Twitter can't know that there is a man in the middle. I've not used Charles, but I've used Fiddler2. Try that one.
http://www.charlesproxy.com/documentation/proxying/ssl-proxying/
http://www.fiddler2.com/fiddler/help/httpsdecryption.asp
Decrypting HTTPS works by the proxy making its own certificate, and giving it to the browser. The browser will notice it connects with a bad certificate and give a warning, but the server (Twitter) will just see the proxy as another browser. The proxy-server connection uses Twitter's certificate, so it's still secure.
Perhaps this is your problem:
Q: Can Fiddler intercept traffic from Apple iOS devices like
iPad/iPhone/iPod Touch and Android devices? A: Yes, but these devices
may not be compatible with the default certificates Fiddler generates.
To resolve the incompatibility, you may replace Fiddler's default
certificate generator with one that generates certificates containing
flags (e.g. AKID, SKID) that are compatible with these platforms.
Simply download and install the new Certificate Maker and restart
Fiddler.
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.