If we want to implement this, we either need a wildcard certificate or additional IP addresses on gudrun. Adding extra IP addresses will complicate our network and firewalling setup, using wildcard SSL certs will cost us money if we want to use trusted certificates.

It's funny that this issue just came up here. Some time ago I started an experiment at archlinux.de and enabled https for the whole site. According to the communities' feedback it's very likely we'll keep it. We are using a class 3 wildcard certificate from cacert (which does not cost anything). The downside is that not every distribution has the cacert root cert installed by default and no browser on Windows or Mac has it included.

Anyway: I think it should be possible to use such an cacert certificate for the whole site optionally (means http without ssl will still be available). Every browser in our repo is able to validate it by default.

I wasn't aware of the fact that cacert provides wildcard certificates. Since all our browsers support the cacert certificate, and since a lot of other distributions include the cert by default also, I think a cacert certificate is the way to go.

adding Aaron, as he is the one who already has a cacert account for archlinux.org. @Aaorn: I could send you a csr which you just need to copy&paste into the cacert form to get a signed public key.

PS:it would also be a valid replacement for our dev site.

We can probably afford a "real" certificate, can't we?

A cacert certificate is real enough. And I don't see a reason to waste funds on buying a xxx€ wildcard certificate each year.

I'm sorry, but for me "real enough" doesn't seem to apply when 2 out of 3 mainline desktop operating systems don't have the root certificate. I'd hardly count this as wasting funds, but I don't want to go back and forth on this either as we could always switch out certificates at a later time.

If we go ahead with this, are we going to move everything to https, or just logins for each subsite?

I don't think we should do this unless we have a cert that windows and mac systems will recognize. To do otherwise I think would discourage a lot of new users from trying us.

We're not switching to https permanently though - it's just an option, right?

I mean, new users are going to end up at the http:// site, right?

That is why I asked what is moving to HTTPS. If we did it rewrite-rule based or something to just get login pages on https, then we have a bit of groundwork that will need laying.

I don't care how it's applied, I'd be fine with it for logins only or the whole thing as an https:// option.; I just feel weary about entering passwords in plaintext/http.

Gah, wish I could edit comments without having to post a new one.
Anyway I just wanted to throw in, the way the FreeBSD forums does it, is default to http, but if you add the 's' manually, the entire session will be secured. So I just add the s, then go to the login page, and login and procede to use the forums. This seems like a viable solution here, which should be trivial to accomplish. Right now on here, adding the 's' makes it load a 'dev' site - Why not change that to https://dev.archlinux.org or something and then do something like I said above.

(FYI I just allowed normal users to "Edit Own Comments")

A 10 subdomain certificate is about $100/yr and a wildcard should be able to be had for around $200/yr.

Are you volunteering?

I see 2 problems here: connecting to different sections of the website using https is one and managing a certificate for such connections is the other.

I'm unable to access bbs, wiki, bugs and aur using https. If I open any of: https://bbs.archlinux.org/ https://wiki.archlinux.org/ https://bugs.archlinux.org/
and accept the certificate all I get is secure archlinux.org mainpage.
As all of those hosts share same IP it looks like problem with apache vhost configuration. Even that some pages states its impossible to have vhost with SSL it should be possible to fix this problem without another IP or expensive certificates. Please see following:
http://wiki.apache.org/httpd/NameBasedSSLVHosts
http://wiki.cacert.org/CSRGenerator
http://wiki.cacert.org/VhostTaskForce
with apache 2.2.12 we have another option - SNI. I just tried it with fresh apache insatall and it seems to work - different certificates for different vhosts (not all browsers are supported)
http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI
http://en.wikipedia.org/wiki/Server_Name_Indication
With correct apache configuration we should be able to access mentioned sites using https even with current (selfsigned) certificate.

As for CA: I think CAcert is a nice option. If we use a certificate with subjectAltName fields it should to work flawlessly with most of the browsers.
http://wiki.cacert.org/VhostTaskForce#Interoperability_Test

And last:
aur.archlinux.org is not accessible using https at all; it is hosted on a different server, though.

We have a wildcard ssl cert from cacert now. It just needs to be deployed. So there shouldn't be a need for SNI and such.

I don't really know how to explain this, so I will try explaining it with an example.

Let say that I arrive on the SSL version of the forum (https://bbs.archlinux.org/) and then I want to have a look a the homepage I will be redirected to the unsecure webpage.

Otherwise if I come from the secured homepage (https://www.archlinux.org/) I am directed to "packages" and "Download" in SSL and not for the rest (wiki. forum, bugs, aur)

Some problems which have not been mentioned:
* After login on https://bbs.archlinux.org it redirects to http not https
* Navigation bar style on https://bbs.archlinux.org is missing (not served via https I guess)
And the ones mentioned already by notch and lymphatic:
* https://aur.archlinux.org does not work at all
* Some links in navigation bars (all sites) point to http not https.
Who is looking at fixing these?

Sorry, I had just set up https on all vhosts for testing and never announced it anywhere. It's nice that users tested this despite the lack of any announcement.

I just took it one step further and fixed the bbs base URL to be https instead of http. I also enforced redirections from http to https for the bbs. The other vhosts don't enforce https yet, I am waiting whether any problems appear with bbs. However, as far I know, bugs and wiki work just fine with https, they do not redirect you back to http.

Next task is to add (for now optional) https to AUR.

@Aaron: It seems our certificate will expire end of August, can you have a look?

AUR now optionally supports https, too, please report problems, if any.

@brain0: Thanks, that resolves my first three points I think. Remaining issues I see are:
* As before, on all sites, some links in the navigation bars (and the Arch logo) point to http not https.
* On the AUR homepage, 3 links to the wiki point to http not https.
* On AUR "Package Details" pages, dependencies from archlinux.org/packages are linked via http not https (AUR deps are https though).

> * As before, on all sites, some links in the navigation bars (and the Arch logo) point to http not https.

I didn't edit any of the webapps. And I think that it shouldn't be necessary to navigate www.archlinux.org with https.

> * On the AUR homepage, 3 links to the wiki point to http not https.

Same here. You can report this to the AUR devs, they could check whether you use AUR via https and adjust the wiki links to https, too.

> * On AUR "Package Details" pages, dependencies from archlinux.org/packages are linked via http not https (AUR deps are https though).

This is similar, the internal AUR links are based on the URL you are using, while the ones to the homepage are hardcoded to http://www.archlinux.org/... This can be fixed in AUR, you could file a bug for these issues. I am unfamiliar with AUR code and do not intend to mess with it.

>I didn't edit any of the webapps.
Understood.
>And I think that it shouldn't be necessary to navigate www.archlinux.org with https.
You mean shouldn't be compulsory? I actually do favour enforcing https on all vhosts. Cleaning up the navbar and AUR links also would be simpler then. Perhaps add a very bare landing page with instructions for people with badly configured browsers.

It's silly to enforce HTTPS on the main site. Unless you are a developer there is nothing there needing any of this protection and as crazy as it sounds, the encryption adds a non-negligible CPU cost. I can see this already for the BBS (which I do not disagree with switching), and I am in favor of switching the other sites requiring login, but it doesn't make sense for the main site.

On my work the proxy does not let me access the forums anymore. I recieve the following warning:

The page you've been trying to access was blocked.

The detected certificate validation mismatch is:
-Hostname does not match Certificate name
-Hostname does not match Certificate name
-Certificate not trusted
Transaction ID is 4C4402604C66500DD7F8.

Quoting an early comment by Aaron:

"I mean, new users are going to end up at the http:// site, right?"

Is there going to be further initiatives to make this happen (Dan mentioned something about a bit more work)? Or are we going to stick to https-only for bbs?

I'm not well-versed with the web side of things but from what I've seen and heard so far is that https takes a little more time to initiate, so some users get annoyed if they're redirected to a secure connection when they just want to browse (and not do anything requiring authentication), especially on slow connections. I've also heard about there being no option to have both http and https for bbs, so this might be a technical limitation.

I have the same problem as Ronald, I couldn't access the forum any more since 2010-07-19.
I get a message that "bbs.archlinux.org:443 is using an illegal certificate. The certificate
could not be trusted because the issuer could not be trusted. Errorcode: sec_error_untrusted_issuer"
(translated from german) and the following:

Detailed Message
VERIFY DENY: depth=1, (19) self signed certificate in certificate chain: "CA Cert Signing Authority"
VERIFY DENY: depth=1, "CA Cert Signing Authority" (CA explicitely denied)

If your proxy forbids you to access the forums, then the owner of that proxy is committing fraud. They are abusing their right for signing certificates to claim ownership of any site you visit and are decrypting and reencrypting the traffic. This is serious abuse and their right to sign certificates should be revoked - if your provider forces you to use such a proxy, you should switch to another provider AND report the abuse to the authority that signed their certificate (look in the certificate chain when you visit a https site to get the info). A proxy MUST NOT decrypt https traffic and claim the traffic comes from the original source.


In any case, we'll very soon get a more accepted certificate instead of the CACert one for the time being.

maybe someone can gift us the "real" certificate, by sponsoring them in the main site. has anyone found this possibility viable?
we could ask some on the major enterprices (i.e VeriSign, ipsca, etc) and check if any of those is interested in the proposal. if they don't, we could try the ca-certificates thingy.