i know these old ciphers are insecure, but id rather have https using tls 1.0 on my site than http only for these old browsers
i host a forum and chatroom for old browsers, and want https to work, but the browsers i allow [ie6 and above mainly] only support tls 1.0
i tried cloudflare and setting minimum tls version to 1.0, but that didnt work, so i tried a seperate domain to bypass cloudflare and directly access the site, but even when enabling tls 1.0 and 1.1 in nginx ssl config it still doesnt work, i read something about windows 2000 allowing just 1 cert per ip, and only being able to handle sha1, and not sha2 which letsencrypt uses
how can i get a sha1 cert so these browsers can still benefit from a little security when visiting my site, even if its not much?
My domain is: redtro.net
I ran this command: the setup and stuff to get the needed certs
It produced this output: worked for moden browsers
My web server is (include version): debian 12, hosted at contabo
I can login to a root shell on my machine (yes or no, or I don't know): yes, always worked, why wouldnt it now
I'm using a control panel to manage my site: no, just plain ftp and a nginx config
The version of my certbot is 2.1.0
The issue with 1 cert per IP etc is just on the server side, client side doesn't care about your IP. [Good point about SNI @MikeMcQ!]
Client side, you will have a a set of TLS protocol levels that a client can speak, and within those a set of TLS cipher suites that they are prepared to negotiate with the service.
So your server needs to support both the TLS protocol level that a client will use, and at least one common cipher suite (dictated in part by your certificate key type, RSA being the only real choice for older browsers).
Your domain proxied at Cloudflare requires SNI. If the browser client does not support it that won't work.
If the client does not support SNI, it can connect directly to your nginx server. But, be sure the default server block has your website configuration. Without SNI the default server block is the only one that client can talk to using HTTPS.
I only see ECDSA certs and ciphers for your main domain. Try using RSA cert and setting up matching ciphers. In Certbot I think you just use --key-type rsa and optionally keysize. Note that the EFF has dropped support for Windows more than 1.5 years ago but you should still be able to get a rsa cert with those options.
You might consider a unique domain name just for HTTP for these older clients. You can then monitor access log for that domain name to know when it is no longer needed.
my idea was using secure.forum.redtro.net unproxied to bypass cloudflare
what do you mean by the second part, eff dropped support for windows and stuff, and a rsa cert with a keysize. i did read that win2k supports only a limited keysize or something
im really new to this
thanks for the help regardless tho!
Various alternatives are described there. The most popular are:
Certify the Web (gui)
Posh-ACME (powershell)
simple-acme (cli) (as replacement for win-acme)
Yeah, pretty sure you need to be using an RSA cert. I think that version of Certbot defaults to ECDSA. So, you need to specify --key-type rsa. I am not sure what key-size is appropriate for those older systems. See the Certbot docs for defaults.
oh nonono, i gotta learn to give more info when i make a new post lol. my vps is running on debian 12
i just want to use https on ie6. i heard of self signed certs but those need to be added everytime on every device. makes me confused why they do allow http [no encryption] but dont allow sha1 signing [weakish encryption]. even the microsoft update catalog uses sha1 in their popup window
ill look up what rsa certs are. but can the system even read them if theyre sha2? i honestly have no idea. i diagnose myself with stupid ;w;
sorry, my fault. You did say that. So, nevermind about the EFF and Windows then
@webprofusion is the author of Certify the Web and knows way more about Windows than I do. He said RSA cert was required for those older browsers.
I looked at your cert history and only see ECDSA certs. You should get an RSA cert on your nginx. And setup suitable ciphers there too. The SSL Labs report showed only ECDSA compatible ciphers which is why I mention that.
Don't overthink the SHA thing since you can't do anything about it anyway. Sort out the RSA stuff which is a known issue. I just checked Certbot docs and rsa key size default is 2048 so that's probably fine.
i tried:
sudo certbot certonly --nginx --key-type rsa --preferred-chain "DST Root CA X3" -d mysub.domain.com
and it sort of worked. well, more not then yes. I was able to visit https on ie8 on xp, but i coincidentally also installed MS KB4467770, which i think enabled old versions of tls 1.1 and 1.2 on xp systems [mainly POSready, the os it was meant for]
even tho i didnt get tls 1.1 and 1.2 options in internet options, and it doenst even support much at all [most sites still wont load], it did atleast SOMETHING i think, for example i can now load github [very very very VERY broken], and the https version of the new subdomain i made for this purpose
the new https domain doesnt work on my pentium3 xp machine [using ie8 too, but without this update] tho, which is where my suspicion that the update causes it to work came from.
at this point what can be possible, do i give users a disclaimer and a link to the update + the new subdomain for https and expose my vps ip, or do i just drop the idea and let users use http if they cant support tls 1.2 [or cloudflare accepted tls 1.0 or 1.1, which i still dont understand _what this could be, as the only instances of tls 1.0 and 1.1 i encountered are these systems]. this would also hide my vps ip behind cloudflare again, which i think outweighs any security benefits https on ie8 and 6 may have...
whats you intake on this? thanks for the help so far btw :]
Should a Win2k device even be connected to the internet?!?
yes and no, altho theyre old, i think security by obscurity plays a role too. just like why win98 online and dos are safe too. altho im thinking of xp as an alternative due to it supporting the same ui style [classic], and it turn having 4 more years of patches + the 2017 and 2019 eternalblue stuff patches. and with posready updates updates until 2019, which weeds out most discovered exploits from the years after xp was dropped when most people still used it, and was being actively targeted
That --preferred-chain has been invalid for a long time. Probably would have been ignored and thus just getting the default chain. Where did you get that suggestion?
Which domain name are you testing with? Is it s.forum.redtro.net
It is using an RSA cert but not allowing those TLS connects. You should review your nginx config. This tool is often helpful: Mozilla SSL Configuration Generator Although, it's "old" settings only say it goes back to IE8 on XP.
Your forum.redtro.net domain is proxied at Cloudflare and allows TLS 1.0 and TLS 1.1. But, it is using an ECDSA cert and related ciphers. I don't know how to force their edge to use an RSA cert. That may be a better question for the Cloudflare community forum.
That's pretty much the extent of my knowledge on supporting extremely old Windows user-agents (browsers).
AFAICT, it seems quite hard to serve a TLS connection and cert that the IE6 client will accept.
For those who want to surf the web with this old browser, there is another option to consider: Using a proxy that makes the modern web compatible with IE6.
the no tls 1.0 and 1.1 on my s.forum is weird, as my nginx ssl config has
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers "AES128-SHA:DES-CBC3-SHA:RC4-SHA:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:>
do i replace it with
or to be fair wont that do antying, i did enable tls 1.0 in the nginx ssl config, but thats global. i just tried making s.forum a seperate block, without referencing nginx ssl conf, and added the ciphers it listed but it still doesnt load
I think there are videos out there of XP hosts that were infected with mallware within half an hour after being directly connected to the internet..
yes, your keyword is directly. we figured out doing that isnt a good idea many years ago. we got firewalls and routers blocking stuff now, and its all a lot more secure
Where do you have this? In the http context or just for the one test server block?
Because whatever is set in http level dictates for all the rest. If not set at http level the default server block's ssl_protocols dictates for itself and all the others.
It is not at all intuitive that this is how it works. But, it is the reason that Mozilla configurator shows the protocols and ciphers (and others) outside of a server block in the http context.
The above is most likely explanation although maybe it is possible that your openssl is configured to not allow those older TLS protocols. If so that may need adjusting too. I think this is unlikely but something to consider if SSL Labs continues to report not being able to connect with the older protocols.
Be sure to do a full restart of nginx after making changes to above. A simple reload is not likely enough when changing listening / port criteria.
For further background see this nginx docs section: Server names
I think you are most likely affected by incorrect context for the protocols. I offer this link for further study if that doesn't resolve it.
#old being replaced with a test -- ssl_ciphers "AES128-SHA:DES-CBC3-SHA:RC4-SHA:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SH>
#ssl_ciphers @SECLEVEL=0:ECDHE-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-P>
ssl_ciphers ":ECDHE-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>
server {
server_name OLDs.forum.redtro.net;
client_max_body_size 20M;
root /var/www/fudforum;
index index.php;
access_log /var/log/nginx/fudforum_access_legacy.log;
error_log /var/log/nginx/fudforum_error_legacy.log;
location / {
try_files $uri $uri/ /index.php?$args;
limit_rate 500k;
}
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php7.4-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
location ~ /\.ht {
deny all;
}
listen 443 ssl;
ssl_certificate /etc/letsencrypt/live/s.forum.redtro.net/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/s.forum.redtro.net/privkey.pem;
# Legacy crypto
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
ssl_ecdh_curve X25519:prime256v1:secp384r1;
ssl_ciphers "ECDHE-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:>
ssl_prefer_server_ciphers on;
}
this is my sites enabled config, whichi i guess has some redundant info about the tlsv1 etc being enabled too. but its still not working
because http is in the ssl nginx config im pretty sure
