New answers tagged

1

In general there is absolutely no security benefit to encrypting traffic between services running on the same host. (Localhost traffic can only be intercepted by an attacker that has full access to the server. When they can do that they can already access all data stored on your server directly (from the file system) and won't need to bother with ...


0

Pls check the relevant group policies settings. Because you are using a WSUS in your network, it is common to ban Windows from using the MS Update servers. Which in your case shoulöd not be this way, instead use the setting in the picture. i#ll try to find the english text if you did not manage to understand it.


0

In the server block for crm.domain.com, you should leave both lines uncommented listen 80; listen 443 ssl; in order for the Nginx server, for this server_name (crm.domain.com), to listen on both ports. Hope this helps.


0

Are you using just an IP to access CouchDB or are you using some hostname? I don't think Lets Encrypt works with just IP addresses (even if they are public).


0

Google has confirmed that this is an issue with the way that Chromium handles the ClientHello, how IIS handles things on 2012, and the algorithm used in our root CA's root cert signing. IIS on 2012r2 performs a check with the ClientHello, against every cert in the chain. Chrome doesn't advertise, but does support, the root CA's SHA-512, ECDH cert. So when ...


6

If you only have one IP address, you need to set all sites that are using HTTPS to require Server Name Identification so that IIS knows what cert to use for clients connecting to which site. Either each site needs to use SNI, or you must use different ports, or different IP addresses. By default most webservers assume that if you're coming to them with HTTPS,...


2

Yes, this is possible. Make your own software listen on local loopback alone, e.g. on localhost:8080. Terminate TLS with NGINX. server { listen 443 ssl; server_name www.example.com; ssl_certificate www.example.com.crt; ssl_certificate_key www.example.com.key; ssl_protocols TLSv1.2; ssl_ciphers HIGH:!aNULL:!MD5; #... } As a ...


1

In frontend www-https in bind line add ssl before crt. Without ssl it works as plain HTTP. So: bind *:443 ssl crt /etc/haproxy/certs/www.example.com.pem


1

Please, make sure your certificate signing request (CSR) is not requesting a certificate that is valid for signing only, rather than signing and encryption. If the CSR ask for a certificate valid only for signing and your CA has a policy that allows for encryption even when the request was signing only, then you will likely see this problem... sometimes. ...


0

I wasn't able to find any answer for the above issue so I turned to a different solution. I set up an nginx reverse proxy with SSL termination. This way both http and https traffic is pointing to port 80 on the backend. No more redirects loop


1

Whilst I still haven't proven if <VirtualHost *:443> is actually working properly or not, I did still manage to solve the problem I was having by inserting my configuration for <VirtualHost *:443> outside of the tag. Maybe not a solution to my original question, but that's irrelevant now considering my ProxyPassReverse now works properly.


0

... "GET / HTTP/1.1\n" 400 3279 "-" "-" The line ending in a HTTP request should be \r\n and not \n. Try the -crlf option of s_client to translate an Enter into \r\n instead of only \n. Also the server might have some limit in which time the request should be fully sent and it might not be fast enough to just type everything. ...


0

You did actually send a malformed request. HTTP/1.1 requires the presence of the Host: header, and further with SNI, the content of the Host: header must match the SNI hostname. Try again and this time provide the correct Host: header.


0

Yes, but it won't work with HTTP/2 (which doesn't allow renegotiation) or TLSv1.3 (since the OpenJDK TLS 1.3 implementation does not support post handshake authentication). What you will need to do is: remove clientAuth="want" from the connector configure the web application for CLIENt-CERT authentication configure security constraints to require ...


0

I think the name parameter in shared:name:size needs to be unique per certificate. Multiple server blocks (different domains or subdomains) might or might not share certificates. Therefore, there isn't a one size fits all default value for the name parameter. I would guess they could just default to not sharing the cache between server blocks, but I'm not an ...


1

I haven't read your aws doc links but I have done the certificate apply on AWS ELB, EC2 VM, apache httpd many times. You don't have to follow the aws guide if that does not sound simple to you. You can do it the old fashioned way. That's how I do it. You create a CSR with openssl command in a Linux server and private key and then get the Signed SSL from go ...


0

For nginx you need to use stream and not http. You can add this to your /etc/nginx/nginx.conf stream { map $ssl_preread_server_name $targetBackend { ~^(?<domain>.+).example.com$ 192.168.1.2:443; ~^(?<domain>.+).random.com$ $domain.internal.local:443; } server { listen 443; proxy_pass $targetBackend; ...


2

Your explanation is not really clear enough to answer, but I'll just mention that a certificate is only valid when the site name matches exactly, and subdomains are not an exact match (unless you use a wildcard certificate). A certificate for example.com is not valid for podcast.example.com.


1

You're right that this represents a potential privacy concern: using SNI, the domain name is sent unencrypted. That's why ESNI (Encrypted SNI) was proposed since by Cloudflare, who already implemented it in their CDN. At the time of this writing, browser support is close to zero, but this seems to be the future!


0

Throwing this out there if it helps someone. I manually deleted the certificate from MMC -> Certificates -> Personal -> Certificates, and then added the certificate manually in IIS through the Complete Certificate Request, but here's the deviation - I added it to Personal instead of "Web Hosting".


0

The following config does the trick for me (Ubuntu 20 with Apache2 v2.4.41 and openssl 1.1.1f): SSLProtocol all -SSLv2 -SSLv3 SSLCipherSuite CDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:...


3

You can solve the problem in your option #1 (which, as you said, is a much better approach) by setting the HTTP_X_FORWARDED_PROTO in your nginx config with proxy_set_header X-Forwarded-Proto $scheme; and configuring WordPress to recognize it by appending this line to wp-config.php if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['...


1

Normally I would prefer to do all the heavy lifting on the reverse proxy and keep the backend site that gets exposed as original as possible. Your problem seems to be in essence that the (WordPress) backend generates and uses (absolute) URI’s that differ from what you want visitors to use. You can remedy that by rewriting the (HTML) content that WordPress ...


3

You should be able to tell Apache that the incoming request is being proxied from a HTTPS request with the proxy_set_header X-Forwarded-Proto "https"; declaration in the first setup


7

The problem is that you accidentally installed the certificate to Current User store. When you double-click on PFX certificate, Certificate Import Wizard defaults to Current User\Personal store. It doesn't offer Local Machine store on Windows 7/Windows Server 2008 R2 or older OS versions. Store location selection choice was added in Windows 8/Windows Server ...


0

modify/change /etc/postfix/main.cf like this below: smtpd_tls_cert_file=/etc/letsencrypt/live/host.hostprovider.com/fullchain.pem to smtpd_tls_cert_file=/etc/letsencrypt/live/host.hostprovider.com/cert.pem smtpd_tls_cert_file should point to cert.pem file and not fullchain.pem


0

Solved! And it was the complete opposite of what I was expecting the solution to be. The problem was not on my origin server's end, all the permissions and firewall rules were all set up correctly - this was an issue on Cloudflare's end. Because I had configured the site to use https only, attempting to access the site via HTTP returned 403 forbidden because ...


0

I was able to fix this by putting the proxy_set_header inside the location{} and not the server{} block.


1

You are selecting Full End-to-End encryption for your Cloudflare setup. This means Cloudflare is expecting to connect to an encrypted server, and proxy that connection to the end user. This means your back-end server, the IIS VM, needs a certificate installed, and needs to be bound to 443. If you do not want to, or cannot, install the cert on your VM, you ...


1

From what you've said your front end is hosted by Vercel, your back end by EC2. They're completely independent from a load balancing / certificate point of view. I suggest: Create a certificate for your back end server using AWS Certificate Manager (ACM). Alternately you can import an existing SSL cert into ACM, but then it won't re-issue automatically. ...


0

You need to host your site on Ec2 You need to add your SSL certificate to your site. Then use HTTP/HTTPS Load balancer.


1

That certificate was generated when you install IIS Remote Management Service, and you can remove it if you don't need that, Reference


1

While it's not 100% clear from your question, the assumption here is that HTTPS works for the first URL, but not the second. A certificate is tied to an identity. In the case of a HTTPS certificate, this identity is the DNS name of the server/service being accessed. This DNS name is stored in the Subject Alternative Name (SAN) extension of certificates. ...


0

TLS_CERTFILE=/etc/courier/certificates/certificate.pem This file should be a combination of cert.pem and chain.pem - which should be the same as fullchain.pem. While it is not fully clear what you are really doing (there are some mismatches in the file names you use, maybe typos), it looks for like you are combining cert and private key instead.


2

Even with IIS setup on a shared config with all the nodes, each node's Operating system is able to set SSL binds outside of IIS, which wouldnt be shared between the nodes. So what I believe the issue is an SSL binding on the OS side (not IIS) on the one node and thereby not allowing the match that IIS was asking it to do. To fix that look at the OS SSL ...


0

The second PC needs to know that my.site.com can found on the first PC; you can achieve this either using DNS or by editing the hosts file on the second PC. Without this, the second PC has no way of knowing where to look for my.site.com.


0

In HAProxy 2.1 (Nov 2019), a new feature allows you to change TLS certificates without requiring a reload: https://www.haproxy.com/blog/dynamic-ssl-certificate-storage-in-haproxy/


0

New thing: You have to open port 443 in your AWS security group. You have to explain what "not working mean". Server not listening? Wrong site shown? Browser complains about certificates? (I just deleted an incorrect answer) You have listed ServerName step9productions.com:443 in ssl.conf and ServerName step9productions.com in httpd.conf That ...


1

You will need to perform the certificate generation action on the server with the IP you specified in your DNS A Record. or If that is not possible you can also execute the certbot command with the --manuel flag. (Official Docs) $ sudo certbot certonly --manual # ... # ... Asked for domain name and IP logging # ... -----------------------------------------...


2

The issuer created it. The name of the issuer is embedded as a mandatory field within the certificate. If you want to know who within your organisation dealt with the issuer, then they should be able to help you as their registration authority should be keeping records. The application bound to the certificate can be found by looking through the ...


0

tomcat-reloading-connector is a ready to use solution for hot reloading certificates in Tomcat. You can just download the jar, plug it into your Tomcat (also works with embedded Tomcat and Spring Boot), configure it in server.xml and it will reload the certs automatically shortly after the files change. It's actually similar to the solutions provided by ...


1

An example NginX config would be like this: server { listen 80; server_name mydomain.co.uk; return 301 https://mydomain.co.uk$request_uri; } server { listen 443 ssl; server_name mydomain.co.uk; root /var/www/mydomain.co.uk/html; error_log /var/log/nginx/mydomain.co.uk/error.log; ...


1

The OP chose not to post an answer, but did say that they solved the problem: The problem was that there was were some strange domains added in the search part of /etc/resolve.conf on the host. And when I was trying to make a https request I have been redirected by DNS to some other server responding with plain http. Correcting the DNS settings solved the ...


1

You can use BetterTLS to check the Name Constraints support of various clients. It's open source and made by the Netflix team. BetterTLS is a test suite for HTTPS clients implementing verification of the Name Constraints certificate extension. It works for the browser and for non-browser clients (like Java and Python).


0

The solution for me on a CentOS 8 system was checking the System Cryptography Policy by verifying the /etc/crypto-policies/config reads the default value of DEFAULT rather than any other value. Once changing this value to DEFAULT, run the following command: /usr/bin/update-crypto-policies --set DEFAULT Rerun the curl command and it should work.


0

Me too, I got this error message when I checked the httpd syntax : SSLCertificateFile: file 'C:/wamp64/bin/apache/apache2.4.46/conf/key/certificate.crt\xe2\x80\x9c' does not exist or is empty My problem was the "double Quote" I had pasted. So I deleted it and typed it, then it worked fine.


Top 50 recent answers are included