I have set up an EC2 with WordPress installed on it. It listens on port 80.
I have created an Application-load-balancer on top of it, and used ACM and created a certificate (signed by Amazon), and created an HTTPS listener that forwards it from 443 to 80 on the (1) ec2.
The listener uses ELBSecurityPolicy-TLS-1-2-Ext-2018-06 as the security policy.
I configured a route53 A rule from the domain to the ELB. This works perfectly.
After that I tried to create a Cloudfront distribution - supporting HTTPS only with the correct CN name and a custom certificate (the same cert used in (2)).
I get the infamous 502.
I read a ton of posts about trying to resolve it... and followed this working example to the teeth - https://www.youtube.com/watch?v=9O2bqYqySEY. Nothing works for me. I still get the 502 error
I used openssl (openssl s_client -connect mydomain:443) to try and make sense of it - I get
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 5479 bytes and written 373 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
closed
What strikes me as weird is that it used TLSv1.3 (which I know AWS only added a few months ago).
BTW, when I tried to run the same openssl on the working situation (stage 3) - I saw that it was using TLSv1.2 when it was working.
I also tried to find an option to forcefully get Cloudfront to use TLSv1.2, but I couldn't.
I know many people asked about this topic - yet, I think this is a new issue since v1.3 was added recently and non of the other answers helped.
Any advice?
Thank you
Ok - turns out problem was around the ELB's security policy.
i didn't have it configured to be ELBSecurityPolicy-TLS-1-2-Ext-2018-06 (but rather the default) at the beginning. Then I switched it to be ELBSecurityPolicy-TLS-1-2-Ext-2018-06...
But didn't see any change. After a few hours where I had given up, I checked it again and this worked - so I am guessing it needed some time / caching.
All works fine now.
Related
Only some (not all) users are receiving ERR_SSL_PROTOCOL_ERROR in Chrome when attempting to visit my express site. I am not receiving this error, so it is proving a pain to debug.
I am creating a https server using a PFX file I downloaded from my provider (1&1):
var options = {
pfx: fs.readFileSync('./mysite_private_key.pfx'),
passphrase: 'MYPASSPHRASE',
};
https.createServer(options, app).listen(443);
https://whatsmychaincert.com tells me that the chain is correct but complains about the handshake:
[mysite] has the correct chain.
[mysite]: TLS handshake error:
error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert
internal error SSL Labs might be able to tell you what went wrong
I've googled this with no success, does anyone know what the problem could be? Ty.
In the end I ditched 1&1 and used GoDaddy's CA service and the problem went away.
A possible source of failed handshake could be the lack of an intermediate certificate, ca option of tls.createSecureContext. It should by public on your provider's website.
Hope this helps.
nowadays , when our server (e.g. 1&1) is securely configured , only tls v1.2 and tls v1.3 are supported ..
so how you debug this:
scan your site with SSL Labs Test too see which ciphers are supported , or alternately see in our nginx/apache config
tail -f the server logs , especially the catchall/other_vhosts log files,since ssl protocol errors might be in the site logs and the generic catchall log when the server cannot decide on the name
try to update the users chrome to support at least tls 1.2
chrome has the some command line switches to change its cipher behaviour:
--ssl-version-max Specifies the maximum SSL/TLS version ("tls1.2" or "tls1.3"). ↪
--ssl-version-min Specifies the minimum SSL/TLS version ("tls1", "tls1.1", "tls1.2", or "tls1.3"). ↪
DANGER ZONE:
as last resort you could try to accept legacy ciphers in your nginx-config ( ssl_ciphers directive) like socat OR (very last resort) socat23 to check which version your clients support,
remember to disable everything below tls v1.2 in production environment
I am using the following web2py slice in attempt to use https for a service worker function in a page.
http://www.web2pyslices.com/slice/show/1507/generate-ssl-self-signed-certificate-and-key-enable-https-encryption-in-web2py
I have tried opening web2py with the following line (with and without [-i IP and -p PORT]):
python web2py.py -c myPath/ssl_certificate.crt -k myPath/ssl_self_signed.key -i 127.0.0.1 -p 8000
but https is declared 'not private' and is crossed out. Because of this, I am getting a SSL certificate error when the registration of the service worker is attempted.
Please indicate what is going wrong or whether more information is needed
You mention "https is declared 'not private' and is crossed out". This has to do with browsers disliking not trusted (self-signed) certificates, because that's what trust is all about. If any hacker could just make up a certificate and the https client wouldn't respond with at least a frown, you could still be hacked or sniffed without noticing. Since you don't mention any other error, I assume you get otherwise valid results from the web2py server?
If so, you have setup your self-signed certificate well. If you don't get any valid html response (outside your browsers complaint, of course), you still have an issue with the setup.
If your service worker won't accept the certificate, what you can do (in a test environment at least) is import the self-signed certificate into the machine or service worker certificate repository. The process differs per OS and version.
Hope this helps. If it doesn't, please provide more detail.
The best way to use ssl with web2py is use of the deployment recipes with prodution-grade webservers like apache, nginx or Lighttpd.
Any of the mentioned scripts create a self-signed certificate, and then, you have to fix the generated server config files to a real certificate.
You can buy a real ssl certificate from any of many resellers or get for free from Let's Encript, if you have a real IP, like in a VPS or server.
A simple way to fix the config files is create a simbolic link from the real certificate to the one mentioned in the server config file.
To just test your service worker in your machine or a internal test server, just use a non-ssl port, or like Remco sugested, import the self-signed certificate to client environment.
For over a year I have been running a photo based website that allows customers to order prints, which are subsequently fulfilled by a printing company. Orders are posted in XML format to a designated URL. Recently it has come to my attention that the orders are not being post and I have found the following error when examining the server logs:
[Mon Dec 01 21:17:38 2014] [error] [client XXX] cURL error: [35] Cannot communicate securely with peer: no common encryption algorithm(s).
The tech team for the printing company was able to provide me with some direction, but I remain confused. Initially they informed me that the server currently supports SSLv2, SSLv3 and TLS 1.0 only, and that it was likely that we only have TLS 1.2 enabled on our end. They claimed that nothing was changed on their end, and I personally know that nothing has been modified on ours for months.
When I originally encountered the problem I attempted to update the server packages, but this failed to resolve the problem. Later I thought that perhaps the issue revolved around the security groups for the Amazon EC2 instance, but I am not entirely sure. How would I go about enabling TLS 1.0, assuming it is not already enabled? How would I check what transport layer securities and secure socket layers are currently enabled? Any other suggestions?
If you can route the traffic through an HTTP proxy, you can install Fiddler and see what is in the TLS negotiation info:
By default on most systems libcurl already speaks TLS 1.0 fine if that's what the server wants.
I rather suspect your problem is that the server insists on using a cipher for this URL that libcurl won't agree to. More specifically, I would suspect it is an RC4-using cipher and RC4 is deemed insecure and is disabled by default by libcurl.
I have an IBM HTTP Server and Server [X] ,
I need to create secure connection [SSL] :
by creating KDB file : ibmhttpserverkey.kdb in IBM HTTP Server using iKeyman utility and importing Server[X]'s certificates [cert.PEM] or [cert.der] in ibmhttpserverkey.kdb
it's do-able or not?
I have tried a lot and every time it returns "Error Handshake, no certificate found" even if i installed it using certification manager!
You should be able to import certificates from other key file types such as a p12 database or another kdb. After doing the import check the personal certificates using IKEYMAN to see if the certificate is there. If you then see the "Error Handshake, no certificate found" in the IHS error log it may be you have not specified the certificate to be the default. Also check the VirtualHost entry for port 443 (or whatever ssl port is used) and see if an SSLServerCert directive is defined. This directive can be used to point at a label that identifies the needed certificate. The no certificate found message means that IHS opened the kdb defined by the keyfile directive and could not find either a default certificate or one that is specified using the SSLServerCert directive.
Guide to setting up SSL within IHS:
http://www-01.ibm.com/support/docview.wss?uid=swg21179559
i have a windows 2008 server and a comodo wildcard cerificate.
i also have a couple of applications running under this certificate.
the application and the certificate work fine and are correctly installed.
i have a gprs module from telit that without ssl works fine but when enabling ssl althougth it works it makes 45seconds in handsake to authenticate the server certification.The delay is surely from the handshake because later on the communication is fast enough.
i am searching quite a while for possible problems. i am leaning to believe that the validation of the certification chain is slow.
how can i reduce this time? do you have any other ideas of possible errors or setting issues?
What is likely happening is that you have not installed the intermediate certificates in the chain on the server. This causes the server not to send those to the client and the client needs to fetch them on its own, which causes the delay. Ensure that all certs in the cert chain, except the root, are present in the local machine Intermediate CAs store.
You can use Wireshark or similar tool to look at the network traffic and see what certificates are being sent from the server to the client. If you could capture the client network traffic, you can see whether my theory above is correct or not and what is causing the delay.