incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ali Lown <...@lown.me.uk>
Subject Re: Federating with self-signed certificates
Date Thu, 30 May 2013 10:29:46 GMT
@Bruno:
>> > I'm attempting again to make my wave server federable, and have some
>> > questions that I hope someone can answer:
>> > 1) Is there any wave server out there that will accept self-signed
>> > certificates? I'd like to test this first, before I try ca-issued
>> > certificates (because I'm guessing it may be more difficult to achieve
>> that
>> > and I want to start simple, though I may be wrong).
>>
>> None currently. I can make one available if needed, but the effort to
>> get a certificate from StartCom is significantly less than the effort
>> to make it all work together anyway.
>> Neither route is any more difficult.
>>
>> Understood, I'll go with signed certs then. Any existing wiab servers I
> could use for federation tests, my server having a ca-issued cert?

I have made my server available for testing at wave.eezysys.co.uk.
(It took me >1h this morning to get it setup again in a way that I
think should make it federatable)

>>  > 2) The check-certificates.sh script seems to be outdated, it assumes
>> that
>> > either run-config.sh or run-config.sh.example exist, but none of them
>> exist
>> > anymore (I'm in git master branch). Can I simpy comment out those checks
>> in
>> > check-certificates.sh and go ahead, or is something important really
>> > missing if I did that?
>>
>> The problem with removing the run-config.sh check is that the rest of
>> the script depends on the values it got from that. (In short the
>> script is pretty much useless now).
>>
>> Remove or fix?
>>
>> Would it be appropriate to include those checks at the start of the
> "run-server" ant target?
> They seem to automate part of the checks outlined here:
> http://www.waveprotocol.org/federation/certificates

Hmm. We would need to determine whether they had federation enabled
before trying to run the checks there.

>> 3) The initial setup I'm aiming for is this: use my own desktop pc
>> (running
>> > debian sid), forward whatever ports are necessary in the router (so far
>> > I've forwarded 9898 tcp incoming), and assume people can access my wiab
>> > server through my dyndns subdomain (which is in the form "
>> foobar.dyndns.org").
>> > Is this setup enough for testing federation, or would I need to
>> > purchase/use a domain that *I* fully control (e.g. "foobar.com") in
>> order
>> > to configure it in ways that dyndns may not allow?
>>
>> To allow XMPP communication to work, you need to be able to setup TXT
>> records detailing which port to use for the wave service. I don't know
>> if dyndns allows you to do this.
>>
>
> Just checked this, it looks like for free accounts you can barely do
> anything.
>
> Fortunately I have some regular domains that I could use (e.g. stenyak.com).
> By reading the docs, it looks like I could set a "wave" SRV record that
> points to my dyndns subdomain (foobar.dyndns.org) on port 9898. That dyndns
> subdomain has the A record that actually points to my home network IP,
> where the 9898 port is forwarded to the relevant computer in the lan.
>
> Is this plan correct? Would wave addresses then be user1@stenyak.com,
> user2@stenyak.com, etc?

Yes. That sounds correct.

> If so, does all of this mean that I can only have one wave server on the
> stenyak.com domain, or could I have several, for example a server on
> wave1.stenyak.com and another one on wave2.stenyak.com? (I might try this
> for testing federation in a controlled environment, before I try to
> federate with 3rd party servers)

You can have one wave server per domain-thing. So you can have one at
mydomain.tld. One at sub1.mydomain.tld etc.
And since you specify port in the SRV record, you can have them all at
the same IP if you really wish to.

Also, I _strongly_ suggest using Prosody, rather than OpenFire as the
XMPP server, simply because OpenFire is a huge package with a
confusing set of configuration options, whereas Prosody just has the
one config file to debug when it doesn't work. :)

The instructions on the wiki for it look correct.

@Angus:
Thanks for moving those documents across. You are correct with those
TODOs (and missed one where the certificates document was referring to
the old run-config.sh script, which is now server.federation.config).
The console client was also removed a while ago.

If I get some time, I might attempt to tidy up some of those TODOs,
but I am trying to get a release handled as well here, so if you can
work on them (just ask about any questions directly on the list), that
would be great.

Thanks.
Ali

Mime
View raw message