Tag Info

New answers tagged

1

You have specify that .htaccess is allowed to override directives. Check AllowOverride and make sure it is correctly defined in your virtual host definition.


2

You are missing listen directive in file default-ssl.conf. Add listen 443; in this directive server { server_name example.com; return 301 https://www.example.com$request_uri } By default, if you omit this directive, nginx assume that you want listen on port 80. Here the documentation of this default behavior. Edit: Thanks for comment from ...


3

See Massimo's Answer for the Right way to do it. Otherwise you can add IPs to the certificate's SAN by creating a configuration file with the following (plus any other options you want): [ v3_ca ] subjectAltName = IP:1.2.3.4 Or if you have a bunch of IPs.... [ v3_ca ] subjectAltName = @alt_names [alt_names] IP.1 = 1.2.3.4 IP.2 = 2.3.4.5 IP.3 = 3.4.5.6 ...


-2

If you have two addresses IP or name-based, you need two certs and two https definitions. On Apache httpd this would be two vhost-sections.


5

You really shouldn't be using IP addresses in a SSL certificate; you should setup a proper DNS infrastructure such that you have f.e. internal.yourdomain.com pointing to the internal IP address, and external.yourdomain.com pointing to the external one; then you'll have to put both names as Subject Alternative Names in the certificate, and it will work ...


0

Yes, although haproxy would almost be overkill for this. You could even bind an stunnel with the appropriate certificate to each IP address and make those connect to your central HAproxy. There's not even need to have more than one HAproxy. listen ssl-domain1 bind public-ip-1:443 # <- ssl config here -> server haproxy localhost:6000 ...


-1

I landed here via Google because I searched for the error no listening sockets available, shutting down When I upgraded VisualSVN Server to the newest version it solved my problem.


0

Well a CNAME doesnt change anything. Client is still connecting to the IP, not the name. Though im surprised that CNAME'ing just works, without having to add the new name to the server. Is the connection HTTPS? Who knows. You may be redirected from HTTP to HTTPS or you may not. Impossible to say really without an actually download link to test with. You ...


3

No, your files are not being downloaded via https, since your link is with http. What you need to do is to put your S3 bucket behind CloudFront. In CloudFront, you have the ability to upload a custom SSL certificate to use with your CNAME (and it is free for SNI-based SSL).


0

I have recently put together a short script in order to do the same thing you are trying to accomplish, here are the relevant parts. Be aware that you will get an error at the end as the Invoke-Command is going to reset the WinRM service while you are waiting for the result of the Restart-Service command... $yourCred = Get-Credential domain\account ...


0

I found the issue so I guess I jumped the gun on posting this question, but I'll leave it here - maybe it will save somebody some time. In the /etc/httpd/conf/httpd.conf file, I had AllowOverride set to None still on the production site for the document root directory. Here is what it looks like now (with the redirect working): <Directory ...


0

Neither the root nor the intermediate certificate are trusted by Chrome, which I believe uses Android's native CA set. That set is viewable from settings->security->Trusted credentials. This question over ad android.se, might help further.


2

You need to provide the entire certificate chain in order for it to show up as trusted. Here's the link I got for comodo's instructions on installing the cert chain in apache: https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/637/37/certificate-installation-apache--mod_ssl I got this from ...


0

Found the issue. Although I am setting JENKINS_JAVA_OPTIONS, it wasn't getting set when Tomcat itself was starting. I went into $CATALINA_BASE/bin/setenv.sh and added: CATALINA_OPTS="$CATALINA_OPTS $JENKINS_JAVA_OPTIONS -DJENKINS_HOME=... This sets the requires properties when Java starts.


1

Just wanted to add my experience as I struggled for hours before realizing that my heartbeat file had an unescaped dot in it (/alive.html). Duh. The second problem was that the main domain was not redirecting, but files were. So http://domain.com/hello.html was redirecting to https://domain.com/hello.html, but http://domain.com was not. Here's what I put ...


1

If it's working correctly like that, don't be scared of it. http://wiki.nginx.org/IfIsEvil It is important to note that the behaviour of if is not inconsistent, given two identical requests it will not randomly fail on one and work on the other, with proper testing and understanding ifs can be used. The advice to use other directives where available ...


0

My question is, if I make it a very complication URL name and only make the file available for an hour or so, what are the odds of somebody just guessing the URL and downloading the file? Near zero - the same as someone guessing a 32 character password. Per https://howsecureismypassword.net/, it'd take something like 21 quattuordecillion years.


0

Yes, all these things are possible provided that you can ignore/bypass/trick client side authentication if any. CURL provides the ability to script to do the mimicking, and there is even a Windows version available. If you need to intercept a session, you might try SSLSniff. If you can provide further details we might be able to help a bit more - for ...


-1

Thanks everyone, It seems that the loadbalancer was misconfigured, it kept sending all requests to one of the ports


0

You have configured SSL to the port 443. If you want to have SSL in port 8005, and nothing on 443 port, use this configuration: server { listen 8005 ssl; ssl_certificate /etc/ssl/certificates/project.com.crt; ssl_certificate_key /etc/ssl/certificates/www.project.com.key; ssl_session_timeout 20m; ssl_session_cache ...


1

The "Require SSL" checkbox is exactly what causes all regular HTTP requests to get a HTTP 403 back. Unchecking it does not "break SSL" or anything like it, it just allows IIS to serve a response for HTTP requests There are 2 approaches to this: Uncheck the "Require SSL" checkbox on the website and rewrite all HTTP requests with URL Rewrite Keep the ...



Top 50 recent answers are included