Printable View
Is there anything wrong with this rewrite that is attempting to forward all requests on port 80 to 443?
I get no error, but the port forwarding isn't happening when I connect to the website. It still goes to httpCode:RewriteEngine on
ReWriteCond %80 !^443$
RewriteRule ^/(.*) https://%{edited_out_thanks}/$1 [NC,R,L]
Also, could someone please hit [EDITED OUT. THANKS FOR CHECKING] and let me know if they no longer get an invalid certificate error?
When I tried your link I gotQuote:
This Connection is Untrusted
JimQuote:
marfig.no-ip.org uses an invalid security certificate.
The certificate is not trusted because it is self-signed.
(Error code: sec_error_untrusted_issuer)
[Edit]Edited at the request of the original poster.[/Edit]
Isn't this backwards?Code:ReWriteCond %80 !^443$
I don't think that '%' should be there.Code:RewriteRule ^/(.*) https://${web}/$1 [NC,R,L]
I would instantly stop using any software that didn't raise an error on a self-signed certificate. I doubt anyone wanting to use the site you are setting up would be willing to use such a piece of software.Quote:
Also, could someone please hit https://${web}/ and let me know if they no longer get an invalid certificate error?
If you want to get rid of the error, use a certificate from a trusted "CA".
Alternatively, if you are set on a self-signed certificate, don't forward a specific page (like "http://${web}/certificate_exception.html") and explain to visitors how to temporarily (this visit only) or permanently allow the certificate to be trusted for SSL transmission.
Soma
Thanks jim,
What a load of crap from the people that do these things. This is the price I pay for wanting to provide a secure connection: I'm not trusted.
Sure will be trusted if I pay for a certificate with real cash...
And then someone complains the web is insecure...
Nevermind. I misread what you wanted. That bit should be fine.Quote:
Isn't this backwards?
This is an issue with the entire "web of trust" as a service concept.Quote:
This is the price I pay for wanting to provide a secure connection: I'm not trusted.
*shrug*
That said, you can easily get an SSL certificate for free if this is a personal site.
Soma
Yeah. I think I'm pretty sure about the condition. It's the rule I was not. Took off the %, but...Quote:
Originally Posted by phantomotap
I was inside a goddamn <IfModule> block and didn't notice! *facepalm*
I may have to look harder, unless you want to cut it short ;)Quote:
That said, you can easily get an SSL certificate for free if this is a personal site.
All I've seen are temporary certificates valid for as little as 30 days and as high as 1 year, requesting a payed extension afterwards.
Well, at least you have one issue sorted.Quote:
I was inside a goddamn <IfModule> block and didn't notice!
Right. I forgot. I'm sorry; I'll have to take that back. The free service I was thinking of folded sometime last year into a virtual host provider so that they could offer free SSL to clients on their domains and as you noted others are "free for a year" but make you pay for a given term or something like that.Quote:
All I've seen are temporary certificates valid for as little as 30 days and as high as 1 year, requesting a payed extension afterwards.
[Edit]
Sorry for getting your hopes up. You'd think I'd remember seeing as how I had to deal with this at the time.
[/Edit]
Soma
Still StartSSL offered 1 year... which is more or less the time I would require to keep this bugtracker online. However, luck would have it they were attacked 2 weeks ago and shutdown their control panel. And so payed CAs win. I, you and everyone else loses... and you do wonder about these attackers (hmm!)... and about the whole crap that is SSL certificates... and why the hell can't I just have an SSL connection without any of this crap... and... I should go to bed. It's 5:30 am
What's the point in having a secure connection if you don't know who you're connecting to?
How about it when you know who you are connecting to? There's no solution to web collaboration projects, for instance, that don't involve either spending money on a certificate, or telling the people that trust your server to inform their browsers that self rolled out certificate is ok (something you can't do on chrome, btw).
I don't see my browser complaining about trust when I'm connecting to a non secure website. But it gets up all in a bunch with large bold red letters, cryptic dialogs and looming discourse, that would scare the willies of Chuck Norris, even replacing access to websites that just want to offer transmission encryption with a warning page every freaking single time you try to connect to them.
The whole thing is backwards. Not because Trust shouldn't be a variable to take into account on secure connections, but because Trust should be everywhere anyways. And as such, imposing Trust over a user in such a aggressive manner when the only purpose is transmission encryption, is only a service to fear and confusion and becomes an invitation to use HTTP instead and to hell with HTTPS. Or is there any doubt there's too many a website that would like to offer transmission encryption but just doesn't do it because of the costs involved and of all the mess they'll get into if they try to roll out their own certificate?
...
Fortunately, for this webservice I'm starting, I can accept the cost of asking everyone using it to tell their browsers to accept this certificate. It's a private bugtracker and will be used by only 10 people and all know me. But were I to have a larger audience, including strangers, I couldn't possibly offer them a secure connection with the current mess that HTTPS is in.
So the option of a secure transmission would be taken away from me and I would be forced into a non secure option, simply because of how browsers behave to SSL certificates. And the secure web was served how, exactly?
I call that crap.
StartSSL suspends services after security breach | Netcraft (ref. to other companies)
Also interesting (though you have to import their cert as well)
Welcome to CAcert.org
CAcert.org - Wikipedia, the free encyclopedia
gg
Yeah, I've checked them last night. Not surprisingly, searching for free ssl certificates amounts to a rather small array of options.
CAcert is a perfect example of how the whole HTTPS thing is. Here we have an organization offering nothing more than a whole bunch of effort to end users. And for what real benefit in the end? None whatsoever. Browsers don't ship with its root certificate. CAcert is well intentioned, I make no mistake about that. But just a waste of their, mine, and everyone else's time. And when they finally one day will be able to convince browsers to ship with their certificate, it's probably not through the system of trust they have in place today.
It's my sincere belief that a lobby of sorts intentionally forces Trust into the domain of SSL for the benefit of a group of CAs who want nothing more than make money out of the irrational fear, doubt and uncertainty imposed on users. There are no provisions in place for SSL transmission where Trust isn't or should be a concern. For instance, when the primary objective is to encrypt the transmission and not authenticate or validate both sides.
If certificates coded on purpose could be acquired (this cert was issued for transmission encryption only but doesn't guarantee trust, this other cert was issued for trust, etc) and browsers adopted less intrusive mechanisms for the SSL/TLS protocols, a lot more people would not be jaded by HTTPS, a lot more service providers would be using it, and nothing would be lost in terms of letting the end user know exactly what type of connection they are using without all this mess of intrusive warning pages and importing certificates onto the local machine. Quite possibly offering in the end a more secure web experience. Which is the damn objective.