In IIS7 I have a FTP site and Website for deployment. Everything works fine, the only thing I do not like is that theoretically every user can tamper with the application files on FTP because read/write access is configured for anonymous.
I fixed this by enabling and configuring "Basic Authentication" instead of "Anonymous Authentication" and now I have to provide my domain password during deployment.
Great! So what's the problem?
The problem is that the password is transferred unencrypted.
Question(s): How can I make sure that the password is encrypted (can I use sftp instead of ftp?)
Any thoughts about certificates? I already tried with a self signed certificate but didn't managed to get things running.
Are there other way to deploy software more secure? I tried over https but I don't have the Frontpage Extension which is necessary for this.
Related
I am using Ansible on a Linux computer connecting to a windows 8.1 embedded computer. It's able to connect with username and password over the HTTPS port 5986, but I need to specify the option:
ansible_winrm_server_cert_validation=ignore
The ansible documentation specifies:
The following is necessary for Python 2.7.9+ (or any older Python that
has backported SSLContext, eg, Python 2.7.5 on RHEL7) when using
default WinRM self-signed certificates:
The windows computer has an SSL listener that was configured with Self-SignedCertificates from the powershell script:
https://github.com/ansible/ansible/blob/devel/examples/scripts/ConfigureRemotingForAnsible.ps1
My question is that if I'm ignoring server cert validation, does that compromise the encryption that HTTPS is supposed to provide? or is server cert validation just a separate process of HTTPS?
Thanks
Yes, if you ignore certificate validation as recommended in the default Ansible config for WinRM, your connection is not secure - someone can spoof the target server using a man in the middle (MITM) attack on the HTTPS connection. (There should really be a security warning in the Ansible docs.)
The best alternative seems to be NTLM/Negotiate authentication, instead of HTTPS, removing the need for an SSL certificate. Your Ansible control machine will need to be able to authenticate over NTLM as a Windows user, just like using an SMB file share.
You will need pywinrm 0.2.0 or higher for NTLM/Negotiate support.
Useful links
Why NTLM/Negotiate for WinRM - background on why it's good to avoid the complex setup to install SSL certificates by using NTLM (Ruby based but still useful)
Example Ansible setup for NTLM
More complete Ansible setup including NTLM
Certificate validation is a separate process than encryption. The communication will be encrypted. You can read more on the issues with self-signed certificates but the high level is you remove any way for Ansible to validate who exactly is on the other side of the connection an open your self to a man in the middle attack that HTTPS usually protects you from.
I have a website running on a shared hosting provider (ie. without SSH access). CPanel is installed. Is it possible to install (and just as importantly, renew) a Let's Encrypt certificate automatically without SSH access? Perhaps a CPanel plugin or cron job (for automatic renewals)?
follow this tutorial to for auto renewal https://neurobin.org/docs/web/fully-automated-letsencrypt-integration-with-cpanel/
You can install Lets encrypt SSL using cPanel ssl/tls -->Install and Manage SSL for your site (HTTPS) --> Manage SSL Sites. To renew certificate you need to regenerate it using your account key and Certificate provided by Lestencrypt in first time. I have done successfully that on GreenGeeks shared hosting help of http://wayneoutthere.com/how-to-lets-encrypt-cpanel-shared-hosting/. You can use https://zerossl.com/free-ssl/#crt to generate Certificates and copy to Cpanel.
You can try to install SSL on your domain through cPanel >> Security >> SSL.
If you are unable to find this in your cPanel then you need to install SSL on your domain through WHM.
You will need Let's Encrypt itself to be installed on the server before running any plugin or crontab job (specially that).
I doubt there is a way to do that without SSH connection, specially on a shared server.
I'm developing an application on Azure VM and would like to secure it by using the wildcard SSL certificate that I'm already using with my main domain. The SSL cert works with any *.mydomain.com and the application on Azure VM is accessible through myapplication.cloudapp.net
Based on the research that I've done, CNAME should be the best option to do that (I can't use A record since we need to shutdown the VMs every week and turn them back on the next week and will lose the ip addresses).
My two questions are:
How can I have myapplication.cloudapp.net be shown as subdomain.mydomain.com?
Will doing that make it possible for wildcard SSL certificate to be used for Azure application too?
How can I have myapplication.cloudapp.net be shown as
subdomain.mydomain.com?
Yes - this is just the CNAME forwarding and ensuring that the appropriate SSL certificate is installed on the server.
Will doing that make it possible for wildcard SSL certificate to be used for Azure application too?
Well as you're already exposing the Application through the VM - this should happen seemlessly.
Just a word of caution, you mention that you're using the certificate on the main domain, but haven't mentioned where you're using this. Be aware that, out-of-the-box, you can only assign one SSL per HTTPS endpoint. You can enable multiple SSL certificates on an Endpoint for Azure / IIS using Server Name Identification and can be enabled directly or automatically. If you do take this route, remember to configure your SNI bindings first, then apply the default binding - it kinda screws up otherwise.
I am working with a client who needs SSL on their Email and Web Site.
We have their site hosted on a Rackspace Cloud Site (Wordpress so Apache and all that jazz).
From what I can tell their Email is on an ISS server of their own.
They want to apply this SSL Cert they bought through GoDaddy and apply it to this email server and to the site on our hosting server. Now I am only a Web Developer with enough server knowledge to get sites launched and running, But I don't think you can apply the same SSL Cert on two different types of servers.
What would the solution be for this?
Would you purchase a second ssl? Is that even possible?
Sorry if this is a all completely wrong I am trying to use my limited knowledge of SSL to describe the situation.
I'm pretty sure you can use the same certificate if it's going on two servers as long as they are both using the same domain. You don't need to purchase a second ssl. The tricky part might be if the two servers require different certificate file formats.
Also, just do the CSR part on ONE of the servers (use the one you trust the most). On the other server just install the certificate bypassing the CSR part.
I'm facing a funny issue here.
I got a C# Webforms application running on IIS6. When the user clicks on a certain link, my app makes a REST call to a webservice hosted in the cloud. This call, made by the app running on IIS, fails. We get a WebException, with the message "no response from server".
However, if I try to connect to the same web service, from the same machine, with the same credentials, using SoapUI, the call succeeds. So I guess this means that I can rule out firewall issues, credential issues, and availability of the service.
The code has been tested on numerous other machines (dev, test, staging...), and it worked successfully, so the code itself should not be an issue. I think it's an environmental issue (a setting on web.config or machine.config which prevents outgoing requests).
Any idea as to what that could be?
Thanks!
The reason our REST calls were failing was that we were missing an SSL certificate.
We were trying to make the REST call using HTTPS. The REST service provider's SSL certificate was signed by a well-known CA. However, our server apparently had a hardened build, and the CA's certificate was missing from the certificate repository. Hence, the provider's SSL certificate was considered unsafe.
Sadly, the .Net framework exception had no useful information about this.
We installed the CA's certificate and the issue was fixed.