Moodle

Hi Adam,

Really interesting. When the SSL cert is self-signed we should be falling back to not requiring that. We tested this early on, but it seems it's not working any more.

So, the webserver cert is involved in this process somehow? I was under the impression that moodle was doing it's own self-signed scheme (the cert's visible under admin->networking->peers are NOT the same cert as the server uses... ??

You are right - moodle is doing its own encryption, but as you are using https, it's also https encrypted. There's an optimisation we could do here in "just" signing but not encrypting if we know the transport is https. Tag that one for 1.9

The curl library that we use to make the xml-rpc calls has an option to accept self-signed certs, somehow the code is getting tangled there. It was working.

Donal - what do you think? My guess is that we need to relax CURLOPT_SSL_VERIFYHOST and then check the results with CURLINFO_SSL_VERIFYRESULT to apply whatever level of strictness we want - probably around mnet/xmlrpc/client.php . I can't find the code that did it, but I do remember seeing you test it with a self-signed cert early on.

Hi Adam - the webserver cert is absolutely not involved at all... Moodle generates its own certs and keeps them in the config_plugins table of your db.

So of course, the system assumes that certs are self-signed. BUT the system DOES check to make sure that the cert's CN (canonical name) matches the wwwroot of the webserver that provided it.

I'm still not convinced that this is your issue. It actually looks more like your certificate is getting garbled somewhere along the way, as if for example a character was being dropped.

Hang on - is Adam running this over https on 443? Ah! So maybe I was being too strict in the curl call. Thanks Martin - I'll go check that out.

Exactly - and I'm not crazy after all - we did have it on our dev code.

Originally introduced on the mdl-mnet-rpc branch, here

commit 9a183ae58674229a20bb941d30a89da91e315b4e
Author: Donal McMullan <donal@catalyst.net.nz>
Date: Thu Sep 21 15:10:17 2006 +1200

mnet: A rewrite of mnet to more closely reflect Moodle coding standards

And then see commits (on mdl17-mnet branch)

commit 17140e64cb07d8f94cf4278c7e26bbddb2267322
Author: Donal McMullan <donal@catalyst.net.nz>
Date: Thu Dec 21 14:03:13 2006 +1300

mnet/lib: get_public_key now uses xmlrpc - eating our own dogfood!

commit 17604c6823ee8d4f041c58fdaf6d2062bdc2cb60
Author: Donal McMullan <donal@catalyst.net.nz>
Date: Fri Nov 10 10:48:24 2006 +1300

mnet: Added xmlrpc directory and moved implementation-specific files there

commit 680de120b8df85813bf331848fd8d574da2d4de5
Author: Donal McMullan <donal@catalyst.net.nz>
Date: Thu Nov 9 13:21:20 2006 +1300

mnet: New peer class for all RPC implementations

commit 13122c2e76a912362d5ad4bb6ee9d9e435f39093
Author: Donal McMullan <donal@catalyst.net.nz>
Date: Fri Oct 27 14:39:39 2006 +1300

MNet: Rebase of moodle network architecture on the 1.7 branch

======

I got this info doing

git whatchanged -p -S'CURLOPT_SSL' origin/mdl-mnet-rpc – mnet lib/mnet
git whatchanged -p -S'CURLOPT_SSL' origin/mdl17-mnet – mnet lib/mnet

The code never appears in mdl18-mnet or in cvshead.

It looks like the "remote" host is requesting a XMLRPC doc from the "local" host, and what it's receiving is badly formed somehow. I don't think it's not encrypted, because there's no way for it not to be.

It's possible that the "local" host is encountering an unexpected error and returning something that isn't even remotely XML.

It's also possible that the "local" host is returning a well-formed XML-ENC doc, but the remote host is failing to parse it properly (which would be a problem in mnet/xmlrpc/xmlparser.php).

Looking at

60:SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:func(144):reason(134)

I'd say at least one end is not accepting self-signed certs. From the errors posted by Adam, we're failing at the curl stage (as you point out, it may be the remote end calling back), and I doubt we ever get to see the XML to encode/decode.

I think it's ok to accept self-signed certs by default - I'll update head.

Maybe I should create a switch in config_plugins that allows people to tighten this up if they want (using their favourite db client)?

Feel free to make these kind of fixes in 1.8 as well, as long as they're improvements and don't require extra tables etc

In the interim, I've updated MOODLE_18_STABLE and MOODLE_HEAD to not require that https servers use signed certificates. The commit is attached as a patch to MOODLE_18_STABLE.

Well, those patches did not fix the problem. However, one of the two error messages is slightly different. These are the two I am getting now (oddly, one from the /moodleone/ install of moodle, and the other from /peer/ insall).

From /moodleone/, when trying to hop over to /peer/ I get:

RPC auth/mnet/user_authorise:Payload not encryptedERROR 1:
1:Payload not encrypted

And from /peer/, when trying to hop over to /moodleone/ I get:

RPC auth/mnet/user_authorise:Payload not signed: faultCode 7023 faultString [[encryption-invalid]] ERROR 2:
2:Payload not signed: faultCode 7023 faultString [[encryption-invalid]]

Any suggestions? Anyone working on this bug do IRC? Perhaps we could speed up the debug process with some live 'try this' exercises.

Thanks.

If you go to the page:
admin/mnet/peers.php
on each of your Moodles, and you click on the link to look at the details of the other Moodle, do the "Public Key" and the "Valid Until" appear to be ok?

I don't think Moodle has it's own IRC channel but I (Spaceman`) am often (NZ office hours) in #mahara and #opensolaris on freenode. I'd be happy to run through some stuff there.

First - apologies for slow response; got dragged into another project. I'm no back with some time to devote to this issue again.

Yes, the keys, and their dates appear to be just fine.

What NZ hours are you on? Let me know what hours (local to you) you're around, and I'll make arrangements to catch up with you if I can. 4pm my time is 10am your time - so if you wake up this morning and get online before 11, I can be available.

Thanks,

I don't believe it! For whatever reason, sitting down with it now, it's working. I didn't change anything!!!

No ideas what to report, other than I can no longer recreate the problem for testing and fixing purposes...

Thanks,

Woah! The only think I can think of that might explain that, is if your servers re-keyed, but the dates on your bug report don't really support this. They should re-key every month or so... 28 days if I remember correctly.

Anyway - thanks for the detailed report Adam.

Cheers - Donal

I've just tried to setup networking as well and I am receiving a similar error when going to a peer:

RPC auth/mnet/user_authorise:Payload not signed: faultCode 7017 faultString Your IP address does not match the address we have on record. ERROR 2:2:Payload not signed: faultCode 7017 faultString Your IP address does not match the address we have on record.

Maybe it isn't fixed?

Hi Lori - it seems like this is a different error. Has the IP address of either of your servers changed since you set them up?

I'm seeing this issue. I today downloaded the latest tarballs of moodle 1.8 and moodle 1.9. They are installed on seperate subdomains on the same physical server. If I try to connect via mnet from one of these servers to the other, i see:
RPC auth/mnet/user_authorise:Payload not encryptedERROR 1:1:Payload not encrypted

The public keys look fine. I did regenerate them, just in case.

Does this create an actual file in the moodle directory??

When I was creating my play instances I accidentally forgot to change a value in my config file. When I set up networking, I got the same error as Brian. So I dropped my tables and my moodle dir and started over, and then it worked fine.

So maybe there a discrepancy in a file that moodle creates on install?

Just a thought.

Hi Lori - no, the MNet stuff all goes into the database.
Do you remember which config variable you changed? I might be able to run a test.

It's back..... I now am getting this from one side trying to access the other

RPC auth/mnet/user_authorise:Payload not signed: faultCode 7023 faultString [[encryption-invalid]] ERROR 2:
2:Payload not signed: faultCode 7023 faultString [[encryption-invalid]]

And from the other side trying to access the main site, I get:

RPC auth/mnet/user_authorise:Payload not encryptedERROR 1:
1:Payload not encrypted

.......

OK, I'm a dummy. Original installs had defaulted to share the same moodledata directory. This is bad. Some re-installs later, and I now have 3 networked sites happily talking to each other. My problem entirely. Feel free to close this bug - at least as far as for me goes. I saw someone report a slightly different problem back up the comment thread that might need their own bug ticket and/or further help on this ticket.

Thanks everyone!

I'm getting the IP doesn't match now.

I had to change the ip of one of my instances... when I did this, I deleted the hosts, Re-entered them (because the IP changed,and re-did the keys.

Now I can't get it to communicate at all, and I even deleted some things out of the db (in the hosts and peers mnet tables).

So something is still keyed or holding on to the old ip I think.

Just to add – I did 2 clean install instances and tried to network them and I'm still getting:

RPC auth/mnet/user_authorise:Payload not signed: faultCode 7017 faultString Your IP address does not match the address we have on record. ERROR 2:,2: Payload not signed: faultCode 7017 faultString Your IP address does not match the address we have on record.

HELP! I have to get this working!

Ok It definitely has something to do with openssl_open line in ment/xmlrpc/client.php Line 218 – using 1.8.1

That's when I get the error message. I echoed $payload before when its ' ' and after $payload = faultCode 7017 faultString Your IP address does not match the address we have on record.
But openssl_open does return 1.

So where is this failing?

Lori - are any of the following true:

• You're running at least one of your hosts on a webserver that isn't Apache
• You're using fake web addresses via virtual-host files or somesuch
• One of your webservers doesn't know its own hostname
• Your webserver(s) have multiple IP addresses

Can you tell me what platform(s) you're running these on? Sorry you're having problems with this code... I'll try to help if I can.

Hi Donal,

Everything is on 1 apache server with multiple IP's assigned to 1 card

I have a bunch of websites on 1 ip

I have what is our main moodle instance on 1 ip, and the rest on another.

So Moodle A has xxx.xxx.xxx.17 Trying to network with Moodle B at xxx.xxx.xxx.23 on the same machine

I had it working when moodle A and moodle B were on the same IP but we want secure logins on Moodle A (no login on moodle B) so I re-did my apache config and gave it its own ip. So just as a test I Put another instance up on xxx.xxx.xxx.23 and tried to network moodle B and moodle C, and still get the same message.

This is on SLES 10, Apache 2.2 (I believe). Thanks for helping.

Hi Lori,

Have you tried to renew the keys and copy and paste them to the moodles that you peer?

Under some settings this should be done (renewed) automatically, - but it is not.

BR
Jens

I have many times Jens.

For some more info - I have 3 additional instances on the same ip on the same server all on .23, moohub1, moohub2, moohub3 -
I was testing out the networking with these instances, and those ones still work exactly how they should. But for some reason, It won't go on our ecampus (main point of entry) to eclass.

So its something specifically with those instances. not the server, because if it was the server it would have changed the moohub ones.

Also like I've said before I've done a complete wipe of those instances (db and files) and started from scratch and still no dice.

Lori

Hi All,

After being on holidays, I installed 2 new instances with 1.8.2 and I'm still getting the same error. It is really critical that I get this working.

As an update, I moved the ip back to .23 --> the ip where I share all the other instance – where it originally worked , and it is working again,

The funny thing is, on eClass (2nd instance) I have eCampus (login point) listed as a peer and .17 is still showing as its ip, but connectivity is still good. So it is working now, but I can't use this ip for ssl logins.

So narrowed down, it looks like its probably an apache type issue with having multiple ip's, and virtual hosts. Is there a way around this?

Adam's original problem turned out to be a configuration error. His Moodle instances were sharing a moodledata directory.

The other issues reported in this bug are dupes of 10672

Hi Donal
Me has the same error, but NOT shared directories ...
you may check this on my site direct if you like, please contact me if possible!

Peter