# Existing tls site with no http redirect **URL:** \ **Category:** Help\ **Created:** [December 6, 2015, 6:24pm UTC](https://community.letsencrypt.org/t/existing-tls-site-with-no-http-redirect/5994 "2015-12-06T18:24:23Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![Kevin](https://avatars.discourse-cdn.com/v4/letter/k/2acd7d/32.png) [@Kevin](https://community.letsencrypt.org/u/Kevin)\ **Post date:** [December 6, 2015, 6:24pm UTC](https://community.letsencrypt.org/t/existing-tls-site-with-no-http-redirect/5994/1 "2015-12-06T18:24:24Z")
I have (or had) a vhost with an existing TLS certificate. I’ve never bothered setting up a redirect from a regular http request to the https site, the site never ran as a regular http site. When I tried to get a certificate (certonly --webroot method) i got an authorization error. After setting up a redirect from the http to https it worked fine. Seems like the client should check for an https site if http fails. ---
**Author:** ![eva2000](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/eva2000/32/289_2.png) [@eva2000](https://community.letsencrypt.org/u/eva2000)\ **Post date:** [December 6, 2015, 6:38pm UTC](https://community.letsencrypt.org/t/existing-tls-site-with-no-http-redirect/5994/2 "2015-12-06T18:38:26Z")
did you site originally have HSTS header set ? that would force subsequent visiting folks to go to https version too even if you didn’t set a http to https redirect curious what was your full webroot command line syntax you used ? ---
**Author:** ![Kevin](https://avatars.discourse-cdn.com/v4/letter/k/2acd7d/32.png) [@Kevin](https://community.letsencrypt.org/u/Kevin)\ **Post date:** [December 6, 2015, 6:51pm UTC](https://community.letsencrypt.org/t/existing-tls-site-with-no-http-redirect/5994/3 "2015-12-06T18:51:26Z")
the https does have HSTS header. When I setup the http redirect I added an HSTS header on that request as well. command line: letsencrypt certonly --webroot -w /sites/subdomain.example.com/web -d [subdomain.example.com](http://subdomain.example.com) I use nginx so don’t use the fully automated version. Also this is on Gentoo Linux and I used the client from their package manager. ---
**Author:** ![selecadm](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/selecadm/32/5114_2.png) [@selecadm](https://community.letsencrypt.org/u/selecadm)\ **Post date:** [December 6, 2015, 6:54pm UTC](https://community.letsencrypt.org/t/existing-tls-site-with-no-http-redirect/5994/4 "2015-12-06T18:54:24Z")
HSTS header must never be sent over plain HTTP, it violates [RFC6797](https://tools.ietf.org/html/rfc6797). ---
**Author:** ![Kevin](https://avatars.discourse-cdn.com/v4/letter/k/2acd7d/32.png) [@Kevin](https://community.letsencrypt.org/u/Kevin)\ **Post date:** [December 6, 2015, 6:56pm UTC](https://community.letsencrypt.org/t/existing-tls-site-with-no-http-redirect/5994/5 "2015-12-06T18:56:20Z")
ah, i’ll remove it then, but that isn’t related to this the issue since let’s encrypt worked once the redirect was in place, even with an invalid header. ---
**Author:** ![eva2000](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/eva2000/32/289_2.png) [@eva2000](https://community.letsencrypt.org/u/eva2000)\ **Post date:** [December 6, 2015, 6:58pm UTC](https://community.letsencrypt.org/t/existing-tls-site-with-no-http-redirect/5994/6 "2015-12-06T18:58:30Z")
[quote=“Kevin, post:5, topic:5994, full:true”] ah, i’ll remove it then, but that isn’t related to this the issue since let’s encrypt worked once the redirect was in place, even with an invalid header. [/quote] yeah strange have you checked /var/log/letsencrypt/letsencrypt.log for clues as to what happened ? ---
**Author:** ![selecadm](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/selecadm/32/5114_2.png) [@selecadm](https://community.letsencrypt.org/u/selecadm)\ **Post date:** [December 6, 2015, 6:58pm UTC](https://community.letsencrypt.org/t/existing-tls-site-with-no-http-redirect/5994/7 "2015-12-06T18:58:48Z")
Have you tried using _–tls-sni-01_ instead of _–webroot_? ---
**Author:** ![Kevin](https://avatars.discourse-cdn.com/v4/letter/k/2acd7d/32.png) [@Kevin](https://community.letsencrypt.org/u/Kevin)\ **Post date:** [December 6, 2015, 7:45pm UTC](https://community.letsencrypt.org/t/existing-tls-site-with-no-http-redirect/5994/8 "2015-12-06T19:45:43Z")
I did not realize --tls-sni-01 was an option. It didn’t show up in help for me (in the full help it only shows an --tls-sni-01-port option). Digging in github it appears that might be for standalone only mode? If it works in webroot too then that might be my fix. I don’t want to issue a bunch of certs from LE just to test various options but I’ll probably try this with a different site. ---
**Author:** ![Kevin](https://avatars.discourse-cdn.com/v4/letter/k/2acd7d/32.png) [@Kevin](https://community.letsencrypt.org/u/Kevin)\ **Post date:** [December 6, 2015, 7:49pm UTC](https://community.letsencrypt.org/t/existing-tls-site-with-no-http-redirect/5994/9 "2015-12-06T19:49:14Z")
ugh, think i kind of figured out some of this. I may have defeated a check in LE for a non-existant site. I have several vhosts. My main blog one does have an http redirect (previously with an HSTS header, now gone). It’s also set as the default server. So when LE tried to connect to [http://subdomain.example.net](http://subdomain.example.net) my default server redirect grabbed it and sent it to by blog’s ssl site instead. I can see the 404 request errors in that site’s weblog. ---
**Author:** ![tlussnig](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/tlussnig/32/2053_2.png) [@tlussnig](https://community.letsencrypt.org/u/tlussnig)\ **Post date:** [December 6, 2015, 11:16pm UTC](https://community.letsencrypt.org/t/existing-tls-site-with-no-http-redirect/5994/10 "2015-12-06T23:16:37Z")
I can also say that if LE have to goal to support encryption every where, the requirement for HTTP on verification, even if i know the reason because of stupid setups, is an more than arguable decision. Even DNS records could be hard to manage. So there should be an options to enable HTTPS for example after email authorisation via whois record.