Running certbot did not give me https

Help
41

As for the other issue... caching perhaps?

1 Like
42

Thats what i thought at first too... But its every device on the network cannot access that site, but when i get off the network, works fine. Ill make a new topic for it.

2 Likes
43

Link to the new topic.

2 Likes
44

Change this:

to just:

    RewriteEngine On
    RewriteCond %{HTTPS} !=on
    RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1
2 Likes
45

@rg305

That's already been replaced by certbot. I'm not sure with what though.

2 Likes
46

@griffin, I just don't get why all examples always check the name before redirecting.
If the block has the server_name, then it's a redundant name check.
If the block has no server_name ("default"), no harm is done by sending those requests to HTTPS.

And in the worst possible case, when an alias is added above that section but not included in that section, that alias doesn't get redirected and might actually reach a document root that it wasn't intended to reach. As an example: Over time, the document root may get changed in HTTPS (only).
[Apache will always try to serve something!]

2 Likes
47

@rg305

I totally get it. I think it's just generic, "safe" coding on the part of certbot.

2 Likes
48

@rg305

If you want to be really efficient, according to Apache this is the very best way:

<VirtualHost *:80>
ServerName newkiddintown.com
ServerAdmin webmaster@localhost
Redirect permanent "/" "https://newkiddintown.com/"

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<VirtualHost *:80>
ServerName www.newkiddintown.com
ServerAdmin webmaster@localhost
Redirect permanent "/" "https://www.newkiddintown.com/"

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Take note that there are no rewrites and no DocumentRoots.

2 Likes
49

Why have two blocks?
They can be combined easily with one alias line.

2 Likes
50

They are separate server names redirected to separate addresses. This is necessary for HSTS.

2 Likes
51

You're saying they serve different content?
If not, then they are one and the same.

It can still be combined - if you use an Apache variable instead of hardcoding the name.
[HTTP_HOST]

2 Likes
52

Howcome?  

3 Likes
53

They serve NO content. They have NO DocumentRoots. They only redirect.

2 Likes
54

But they have no TLS also.
So if I redirect my site to yours (badly)...
Then I can brake your sites' HSTS?

2 Likes
55

Because HSTS to my knowledge requires...

http://domain.com -> https://domain.com

http://www.domain.com -> https://www.domain.com

Only the protocol is supposed to change, not the host name.

2 Likes
56

Correct. Those VirtualHosts are only there to catch incoming http connections on port 80 and redirect them to https.

I don't understand how this relates.

2 Likes
57
2 Likes
58

I seem to remember JuergenAuer mentioning a while back that...

http://domain.com -> https://www.domain.com

was inappropriate for HSTS and that it should be...

http://domain.com -> https://domain.com -> https://www.domain.com

First redirect to https then to www or apex.

2 Likes
59

http > http > https is bad
http > https is good

I don't know that that it really matters so much if they aren't to/from the exact same FQDN.

1 Like
60

I only mentioned http -> httpS -> httpS

1 Like