[00:58] niemeyer: got a better fix for signing bug [00:58] will propose in a few minutes [01:06] niemeyer: did you fix lbox so it doesn't mess up the milestone of a bug ? [01:06] if so, thank you :) [01:08] davecheney: Yo [01:08] davecheney: Morning [01:08] davecheney: I didn't yet, sorry [01:19] niemeyer: weird, i wonder why lbox propose didn't screw up the milestone on https://bugs.launchpad.net/juju-core/+bug/1061941 [01:20] maybe because it's a different project [01:48] davecheney: Perhaps the milestone picking logic is actually right [01:48] davecheney: What I did was to deactivate 1.3 a while ago [01:48] \o/ ! [02:34] davecheney: Bed time here [02:34] davecheney: Have a good time [02:34] * niemeyer => zzzzzZZZ [07:28] fwereade__: morning [07:32] wrtp, heyhey [09:17] davecheney: hiya [09:18] davecheney: if you have a moment, this evening, it would be great if you could try to provoke that test failure - i'd like to get that CL submitted. [09:23] wrtp: that is the thing [09:23] the test never fails [09:23] davecheney: have you tried raising the iteration count? [09:23] davecheney: (did you see my reply BTW?) [09:24] i think i may not have [09:24] basically i reveted state.go [09:24] and the test still passed [09:24] so, what is the test testing ? [09:24] davecheney: i only replied an hour ago [09:24] davecheney: it's testing a race condition [09:24] davecheney: read my reply for details [09:24] ok, i'll go upstairs and read it [09:25] davecheney: ta [09:45] guys, I need to take a somewhat extended lunch; https://codereview.appspot.com/6734046 is pretty trivial if anyone is bored ;p [09:51] fwereade__: reviewed [10:20] moin. [10:29] Aram: hiya [12:22] this fails for me.go test labix.org/v2/mgo [12:23] could someone else try it, and let me know if the test passes, please. [12:23] one min\ [12:23] Aram: thanks [12:24] wrtp: failed [12:24] Aram: thanks [12:25] wrtp: I remember now, actually. [12:25] it never passed for me [12:25] I remember that error from when I started using mgo [12:25] it never worked right here [12:25] Aram: it's strange because it looks like that js is ok [12:25] Aram: that is, i can't see how rs1a could be undefined. [12:26] Aram: ah, i see [12:27] yeah [12:27] Aram: maybe the server ports have changed or something [12:27] what momgodb version do you have? [12:27] this is 2.0.4 [12:27] Aram: the one we're using in ec2, i think [12:28] Aram: 2.2.0 [12:31] Aram: hmm, i think it might be failing because i don't have a "supervisorctl" command [12:31] (whatever that's supposed to do) [12:32] yeah, I don't have that either [12:34] Aram: hmm, that doesn't seem to have fixed it [12:57] Moooorning [13:01] niemeyer, heyhey [13:07] niemeyer: yo! [13:08] niemeyer: any hints as to how i can get mgo tests passing? it seems like it's something to do with supervisord (which wasn't installed), but i've failed to get it working even when it is. [13:09] wrtp: You have to run make startdb [13:09] niemeyer: ah! [13:09] wrtp: It sets up the 12 servers, etc [13:09] wrtp: It doesn't restart them across runs [13:10] niemeyer: right - i see now. that was not so obvious :-) [13:14] wrtp: Anything you think is broken there? [13:15] niemeyer: i just wanted to check that i could connect to mongodb with Go's TLS, so i made some changes to allow that and wanted to verify that everything was still working [13:15] niemeyer: i do get one test failure, even after running startdb, BTW [13:15] wrtp: I will work on that on my own time [13:15] niemeyer: it looks like session.DatabaseNames doesn't always return the names in sorted order [13:15] niemeyer: ok. you don't want to accept it as a contribution? [13:16] wrtp: Is juju distributing TLS certificates properly? I'll happily take that as a contribution. :-) [13:16] niemeyer: i need to talk with you about that [13:17] niemeyer: i didn't want to build an implementation without deciding what to do first [13:17] wrtp: Understood.. the point is that I'm happy to use my own time to work on mgo as I've been doing since day one. We don't have to spend our time to do that. [13:17] niemeyer: that's ok. [13:17] niemeyer: it was only 10 minutes' work [13:18] wrtp: Cool, but it wouldn't be to implement it properly [13:18] niemeyer: no? it's true i'm probably unaware of the subtleties [13:19] niemeyer: i thought something like this was probably sufficient: http://paste.ubuntu.com/1286877/ [13:24] wrtp: Quite possibly [13:24] wrtp: That's what Dave suggested too [13:27] niemeyer: here's my half-baked plan for key distribution BTW: http://paste.ubuntu.com/1286895/ [13:33] fwereade__: I think there was some misunderstanding on the Cleanup review [13:33] fwereade__: But perhaps it's for the best [13:34] niemeyer, oh, sorry, perhaps there was [13:34] niemeyer, what did I miss? [13:34] fwereade__: The suggestion was to run RemoveAll, but not to scan through all documents pending of cleanups at once [13:35] niemeyer, yes -- that changed because it appeared to make the code simpler, and I couldn't think of a serious drawback... [13:36] niemeyer, given that I was looping until I found a valid cleanup doc *anyway*, I thought it was easier to just keep on looping :) [13:36] i've got to reboot. back in a mo. [13:36] fwereade__: It may only load the system at once a bit more, but it sounds worth trying [13:36] niemeyer, yeah, it seemed to follow the spirit of your other suggestions :) [13:37] fwereade__: I think the cleanups doc is fine to be deleted out of a transaction too, btw [13:38] niemeyer, I thought "better safe than sorry" there, on the basis that it's a new feature whose context is yet to be completely determined [13:38] fwereade__: We did its intended action before getting there, and the action is idempotent, so any mixup should be fine [13:39] niemeyer, true enough, happy to change [13:40] fwereade__: For clarity, the dangers we can incur by not using a transaction, in that specific case, is seeing the change being done again [13:41] fwereade__: Because if the transaction failed on the insert side before being finished, someone else will attempt to apply the transaction again, and may end up reinserting the doc [13:41] fwereade__: After that transaction is finished, that doc is never seen in a transaction again [13:42] fwereade__: So the worst that can happen is Cleanup running the same cleanup twice, which is not a big deal due to its nature [13:42] fwereade__: I suspect that will be true in general for cleanups [13:42] niemeyer, hope so :) [13:43] fwereade__: If you want me, I'll be in my bunker [13:43] haha [13:44] niemeyer: any thoughts on my key distribution sketch above? [13:45] wrtp: I started reviewing a branch before you posted, and I haven't yet finished [13:45] niemeyer: ok, np [13:46] niemeyer: i wasn't sure you noticed the paste. [13:47] fwereade__: LGTM, thanks a lot for the rounds [13:47] wrtp: np [13:47] wrtp: SO.. === wrtp is now known as rogpeppe [13:47] niemeyer: so... [13:47] rogpeppe: We don't need --sslOnNormalPorts.. we don't even use normal ports [13:48] niemeyer: ok. that just came from a web page. i'm not fully cognizant of the implications of all the mongod flags :-) [13:49] niemeyer: (i thought perhaps it might allow non-ssl connections without that flag) [13:50] rogpeppe: We want --ssl, I think [13:50] rogpeppe: I don't have a lot of experience with ssl on mongo myself, to be honest [13:50] rogpeppe: 10gen plays a trick I don't find so nice [13:50] niemeyer: i was going from this page: http://docs.mongodb.org/manual/administration/ssl/ [13:51] rogpeppe: Their own packages don't have ssl built-in.. you have to pay for a subscription [13:51] niemeyer: yeah, that's why you had to do your own build, right? [13:51] All things considered, I guess it's a fine way to stay in business, though [13:51] rogpeppe: Yeah [13:52] niemeyer: if people can't be bothered to do a build, then it's their problem i guess. [13:52] niemeyer: (you didn't have that easy a time of it AFAIR though!) [13:52] Hmm.. "Add the “ssl=True” parameter to a PyMongo".. I'll have to investigate what's the standard way drivers are handling that [13:53] "mongodb://localhost/?ssl=true&sslverifycertificate=false" [13:53] interesting.. [13:53] Anyway, sorry, derail [13:54] rogpeppe: Only because it takes forever.. otherwise it was somewhat okay [13:54] rogpeppe: in your sketch, I'm not entirely sure of what lines 12-15 mean [13:55] niemeyer: we've got to make the public key available somewhere outside of the state, right? [13:55] niemeyer: and the server itself must generate the public key, i think [13:55] rogpeppe: Well, we can only generate the public key by generating the pair [13:56] niemeyer: exactly [13:56] rogpeppe: I'm not sure we want to do that at the server side, though [13:56] rogpeppe: It means the client has to trust the server blindly, at least once [13:56] niemeyer: and we don't want to make the private key available in cloudinit [13:56] niemeyer: there's another way around that, i think, which is orthogonal to this [13:57] niemeyer: which is to have a client-specified value that's put into the state. [13:57] rogpeppe: That's a bit related to that conversation we had the other day regarding push vs. pull [13:57] rogpeppe: Erm.. sorry [13:57] rogpeppe: That was confusng [13:58] rogpeppe: The conversation regarding bootstrapping via ssh rather than via cloud-init [13:58] niemeyer: i remember the conversation [13:58] rogpeppe: Or perhaps via both, but pushing the changes via ssh [13:58] niemeyer: don't we have the same problem there. we must trust the server blindly the first time. [13:58] rogpeppe: Let me look at how we bootstrap today for a sec.. just a moment [14:01] rogpeppe: Okay [14:02] rogpeppe: I guess the problem we have is pretty much the same as the problem we just solved with the password [14:02] niemeyer: if we could write to environments.yaml, our problem would be simpler [14:03] rogpeppe: Seems like a red-herring [14:03] rogpeppe: How did we solve the problem of initializing the password? [14:04] niemeyer: we changed it [14:04] rogpeppe: Yep [14:04] niemeyer: but if the password is specified in environments.yaml, we can't do that. [14:04] rogpeppe: Hmm.. I lost you [14:05] rogpeppe: The password *is* specified in environments.yaml, and we do that [14:05] rogpeppe: environments.yaml seems like a red-herring [14:05] niemeyer: perhaps i'm misunderstanding you. the password in environments.yaml is so we can authenticate ourselves to the server. what we're trying to do here is authenticate the server to the client, no? [14:06] rogpeppe: The problem we have is exactly the same.. we have a private key that we want the server to hold without exposing to everybody that can read cloud-init [14:07] niemeyer: ok... so who generates the private key? [14:07] rogpeppe: We do [14:07] rogpeppe: The client [14:07] niemeyer: how does that help? [14:08] niemeyer: i suppose it means we don't have to wait for the public key to become available [14:08] rogpeppe: It's the only way for the client to be able to tell it's talking to the right server [14:08] niemeyer: i don't see how it helps [14:08] rogpeppe: Hmm.. expand? [14:09] niemeyer: when we connect for the first time after bootstrap, how do we tell if we're talking to the right server? [14:09] rogpeppe: When you connect to your bank in your browser, how can your browser tell it is talking to the right endpoint? [14:10] rogpeppe: (or at least hope so ;) [14:10] niemeyer: because your browser has stored a public key of the bank. [14:10] rogpeppe: Almost, but close enough [14:11] niemeyer: so where do we store the public key that we generate at bootstrap time? [14:11] niemeyer: ah, i suppose we can use our local key to sign a certificate for the server [14:11] niemeyer: and then use our local key as the root CA [14:12] niemeyer: i'm not sure that works though [14:13] niemeyer: hmm, maybe. [14:13] rogpeppe: Why? [14:15] niemeyer: i guess we'd need another field in environments.yaml [14:15] niemeyer: to hold the original signer's certificate [14:15] niemeyer: we could overload authorized-keys, i suppose [14:16] rogpeppe: Uh.. why the obsession about environments.yaml? [14:16] rogpeppe: and how's authorized-keys related to the problem? [14:16] rogpeppe: This is the ssh key, and it works well [14:16] rogpeppe: No need to fiddle there [14:17] [15:09:02] niemeyer: when we connect for the first time after bootstrap, how do we tell if we're talking to the right server? [14:17] rogpeppe: environments.yaml seems like a red-herring [14:17] :) [14:17] :-) [14:17] niemeyer: i'm not sure how to answer my question above [14:17] rogpeppe: You've already answered it? [14:18] niemeyer: my answer only works if we know what key signed the server's cert [14:18] rogpeppe: Of half of it, anyway [14:18] niemeyer: and that's something that needs to be specified in environments.yaml AFAICS [14:18] rogpeppe: Exactly, that's what we're handing off the key to the server [14:18] s/what/why [14:18] rogpeppe: lOL [14:19] rogpeppe: We can do whatever we want.. yes, it may be in environments.yaml, it may be in ~/.juju/envname.cert, or whatever [14:19] niemeyer: ok, so we've handed off the key to the server. now we connect again, and the server presents a certificate. how do we tell if that certificate is valid? [14:21] niemeyer: ok, sorry. i was using environments.yaml as a place-holder for "somewhere with client configuration information". of course it could be stored elsewhere too. [14:21] rogpeppe: You've already answered it: [14:21] niemeyer: ah, i suppose we can use our local key to sign a certificate for the server [14:21] niemeyer: and then use our local key as the root CA [14:22] niemeyer: the reason for the possible authorized-keys possible-red-herring is that we already have a local key, which we use to connect with SSH. we could use that very same key to sign the initial certificate. [14:22] niemeyer: rather than requiring everyone to generate another key just for juju [14:23] rogpeppe: Nope.. different worlds [14:23] niemeyer: ok [14:24] niemeyer: so... in this proposed world, we have our own key distribution problem at the client side. [14:24] niemeyer: everyone that needs to bootstrap an environment must have a private key signed by the root key [14:25] rogpeppe: This seems to put a simple problem in somewhat of a dark perspective [14:26] rogpeppe: I'd put it more lightly as [14:26] rogpeppe: When we bootstrap, we sign the key we hand off to the server [14:28] niemeyer: i suppose i'm slightly concerned at the change in juju usage implied here. before, you could just bootstrap anywhere, and connect to the environment from any other place as long as you had an authorized ssh key. [14:29] rogpeppe: That feels like an entirely different context than the one we're talking about [14:29] niemeyer: now you can only bootstrap if you've got a private key that is derived from the root key. [14:29] niemeyer: (the root key being the one mentioned in the other environments.yaml files, so that they can connect) [14:30] rogpeppe: Sorry, I think either you see something I don't, or you're creating a picture that I'm not perceiving [14:30] rogpeppe: Generate key, sign, send to server, profit.. [14:30] rogpeppe: Where's the pain coming from? [14:31] niemeyer: connecting again [14:31] rogpeppe: yes? [14:32] niemeyer: if i'm connecting from a different host, i've got to verify that the bootstrapped environment's key was signed by the original key [14:32] niemeyer: so i need to know about the original key [14:32] rogpeppe: Yes you do need to know about the server certificate if you want to validate the server is who we think it is [14:32] rogpeppe: That's called authentication [14:33] rogpeppe: Something we conveniently ignore right now [14:33] niemeyer: we're actually verifying the client that did the bootstrap in this case. [14:33] i think [14:33] rogpeppe: ? [14:34] niemeyer: that's where the chain of trust starts [14:34] niemeyer: which seems good, actually. [14:38] niemeyer: hmm, i guess we'll have to issue the initial certficate with a very limited lifespan. [14:38] niemeyer: no that doesn't work [14:39] niemeyer: i'm not sure how we'll do the interaction to sign the new key when first connecting to the state. [14:40] rogpeppe: We can create a temporary cert to sign the trashed private key [14:41] niemeyer: the server does that? [14:41] rogpeppe: We cannot create the certificate in the server because then we cannot talk to the server and know we're talking to the right server [14:41] niemeyer: perhaps we need to run a little server that the client connects to, reads the new public key from the server, and sends back a signed cert [14:42] niemeyer: indeed [14:42] niemeyer: but we can (and should) generate a new private key on the server, and get that signed [14:43] rogpeppe: We can generate the private key on the client and sign it on the client where we have the certificate [14:44] niemeyer: how do we send it to the server? [14:45] niemeyer: we could put it in the state, i guess, but that seems wrong to me [14:47] rogpeppe: Why? [14:48] niemeyer: for the same reason we don't put admin-password in the state [14:49] rogpeppe: One of the reasons we don't put it in the state is because nobody needs it [14:51] niemeyer: i thought it was a security issue too - we don't want anyone with access to the state to be able to impersonate the state server. [14:51] s/thought it was/think it might be/ [14:52] niemeyer: of course, they can only do that if they subvert DNS too [14:53] rogpeppe: Give me access to the state without a private key, and I'll dig the key out of the state server in a short while [14:53] niemeyer: that's true of all our passwords too, of course. (with the exception of admin-password itself) [14:54] rogpeppe: No, you cannot figure the password actually, but that's a derail [14:55] rogpeppe: The points are: [14:56] 1) We're consciously not handling authorization anywhere yet [14:56] 2) Anyone with access to the state *today* can do whatever they want [14:56] 3) That includes getting access to the state server [14:56] 4) We're walking towards having a true API that manages authorization [14:57] 5) With authorization, we can prevent people from having access to things they shouldn't [14:57] 6) Even in the future, anyone that gets access to a state server *database* will have the private key for the server anyway, no matter if the key sits within the state or not [14:58] That's it, I think [14:59] niemeyer: i suppose it just *feels* more secure to have the server generate its own private key. but you're probably right that it's unnecessary. [15:00] rogpeppe: Well, I won't argue about that. If you know why it's more secure I'd be interested though. [15:02] niemeyer: it means we're not leveraging future security on current security so much. once a state server has obtained an identity, it can keep it, knowing that no-one else has its private key. that said, i can't think of any attacks in particular that this enables. [15:03] rogpeppe: Yeah, I don't see where the "more secure" bits went in [15:04] rogpeppe: And I see a bunch of issues to solve, such as how to distribute keys to replica sets, and how to ensure the key isn't lost [15:08] hmm, don't know why i was kicked of then [15:08] niemeyer: last thing i saw: [16:04:15] rogpeppe: And I see a bunch of issues to solve, such as how to distribute keys to replica sets, and how to ensure the key isn't lost [15:08] off [15:08] wrtp: Yeah, that was it [15:08] niemeyer: what was the last thing you saw me say? [15:09] wrtp: Nothing after that [15:09] 16:06:29] niemeyer: here's a thought: is it actually possible to change the server's key after it has started running? [15:09] [16:06:52] niemeyer: or will we need to shut down mongod and restart it pointing to the new private key [15:09] ? [15:11] wrtp: Short term, I suppose we have to restart it [15:12] niemeyer: and there's another issue too - how do we ensure that the original certificate (in cloud-init) isn't valid forever, while ensuring we can connect an arbitrary time after bootstrap [15:12] ? [15:12] Oct 18 11:40:53 rogpeppe: We can create a temporary cert to sign the trashed private key [15:12] niemeyer: i'm not sure quite what you mean by that [15:12] wrtp: Temporary cert? [15:12] wrtp: What part? [15:13] niemeyer: yeah [15:13] wrtp: Sorry, can you explain what you don';t understand? [15:13] niemeyer: do you mean a certificate with a short expiry time? [15:13] wrtp: No.. I mean creating a certificate that is itself temporary [15:14] niemeyer: i'm not sure what that means [15:14] niemeyer: stored temporarily? [15:14] wrtp: I don't know how to explain that more simply [15:14] wrtp: Yes [15:15] niemeyer: but the cert is in the cloud-init data; how can it be stored only temporarily? [15:15] wrtp: No, the cert is local [15:15] wrtp: priv and pub keys are in cloud-init [15:16] niemeyer: don't we need to pass a cert in the cloud-init too? [15:16] niemeyer: because we need to sign it with the client's private key [15:17] wrtp: Hm? [15:17] niemeyer: isn't that the basis of our security here? [15:17] niemeyer: how else do we know that the certificate is valid when we're connecting to the state? [15:18] wrtp: Because we have the certificate with which the private key was signed [15:18] Erm [15:18] The public key [15:18] niemeyer: the server has that certificate? [15:18] wrtp: Not necessarily, although we should probably send the public part of it as a sensible thing to do [15:19] wrtp: That's not what the security is based on, though [15:19] niemeyer: oh, i *think* i start tosee. [15:19] to see [15:19] wrtp: A private key is used to sign stuff, and to encrypt stuff for people to have the public key [15:20] niemeyer: i know that. [15:21] wrtp: A public key is signed by a private part of the certificate so that people holding the public part of the certificate can attest that whoever handed off the public key was signed by the private part of the certificate [15:21] niemeyer: i do know how pk auth works, i think [15:22] wrtp: My apologies, but that's exactly what I've been explaining [15:22] niemeyer: i'm just not entirely sure what configuration you envisage here [15:22] niemeyer: i think i might see. i was thinking that the private key would be generated at bootstrap time. [15:23] wrtp: and it will [15:26] Oct 18 11:30:45 rogpeppe: Generate key, sign, send to server, profit.. [15:26] niemeyer: (sorry, i'm feeling particularly dense today) [15:27] niemeyer: i thought that the server side of the TLS connection needed the signed certificate [15:30] wrtp: The server side needs a public key signed by the local certificate and a private key [15:31] niemeyer: hmm, that's what i thought [15:31] niemeyer: so that {public key signed by the local certificate} must go into the cloud-init data, right? [15:31] wrtp: The server side needs a public key signed by the local certificate and a private key [15:31] wrtp: Both need to go [15:32] niemeyer: yeah, sure, the private key too [15:32] how does that tally with this: [16:15:22] wrtp: No, the cert is local [15:33] wrtp: "signed by the local certificate"? [15:33] niemeyer: isn't a public key signed by the local certificate a certificate itself? [15:34] niemeyer: i'm probably getting my terminology wrong, sorry. [15:34] wrtp: It can be if its respective private key is used to sign something else.. but I don't think that matters/ [15:34] ? [15:34] niemeyer: (i was thinking that certificates can't sign things, only private keys can) [15:34] niemeyer> wrtp: A public key is signed by a private part of the certificate so that people holding the public part of the certificate can attest that whoever handed off the public key was signed by the private part of the certificate [15:35] niemeyer: private-part-of-certficate == private-key, no? [15:35] gah! [15:36] wrtp: I suggest reading a bit about PKI.. [15:37] niemeyer: i have read a certain amount, but obviously not the right bits... [15:38] wrtp: http://www.openssl.org/docs/HOWTO/certificates.txt [15:39] niemeyer: that seems to agree with what i thought [15:40] niemeyer: i.e. the private key is not part of the cert [15:40] wrtp: I'm sure.. we're debating this for ages just because we all understand things and are in deep agreement :) [15:42] niemeyer: i'm sorry. but part of my confusion here is about terminology. when you say "public key signed by the local certificate", i find it confusing, because a certificate can't sign things. [15:43] niemeyer: so i'm *trying* to get around to asking how we can limit the lifetime of the certificate we send to the server in the cloud-init data. [15:44] niemeyer: i'm sorry we seem to be having difficulty here. [15:45] wrtp: Do you understand what a root certificate is? [15:45] niemeyer: i believe so [15:46] wrtp: Okay.. what does it do? [15:47] niemeyer: it verifies that some root private key has some attributes [15:47] wrtp: Hmm.. no.. [15:47] wrtp: It signs things [15:47] wrtp: and there is both a private part of it, and a public part of it [15:48] niemeyer: the public part of it *is* the certificate, i believe [15:48] niemeyer: the private key is just a private key, that can be used to sign any number of certs [15:48] wrtp: Nope.. it's a pair [15:49] niemeyer: if i want to sign a certificate request, i can use this command: [15:49] openssl x509 -req -days 10000 -signkey $keyfile -out $certfile -in $reqfile [15:49] niemeyer: that produces a certficate signed by the specified key file. [15:50] niemeyer: there's no inherent pairing [15:50] wrtp: There all those fancy names, but in the end it's good old asymmetric crypto [15:50] niemeyer: indeed [15:50] niemeyer: the different thing about a root cert, i suppose, is that it's self-signed. [15:53] wrtp: So, you use the private part of the key pair that some call certificate, some call whatever they want, to sign things [15:53] niemeyer: yup [15:54] wrtp: The root CA is the public part of it [15:54] niemeyer: yup [15:54] wrtp: The thing we see and can check [15:54] niemeyer: yup. but we also need to check the intermediate certificate too, right? [15:54] wrtp: The private part of the root CA is what signs the public keys we use in the server that you can also call certificate if you want [15:55] wrtp: If there is an intermediate certificate, yes [15:55] wrtp: Then the private key of the root CA signed the public key of the intermediate certificate, and the private key of the intermediate certificate signs the server public key or public certificate if you please [15:55] niemeyer: in this case, there must be an intermediate certificate AFAICS because we don't send the root certificate to the cloud [15:57] niemeyer: ok, in that sense we probably won't have an intermediate certificate. it's that last bit i'm talking about. [15:57] wrtp: The two last sentences contradict each other [15:58] niemeyer: i realised that i meant a different thing to you by "intermediate certificate" [15:58] niemeyer: hence "in that sense" [15:58] wrtp: Intermediate certificate in general is unambiguous [15:59] niemeyer: in this case AFAICS, we've got two certificates in the first instance: the root cert and the cert that we give to the bootstrap instance. [15:59] http://en.wikipedia.org/wiki/Intermediate_certificate_authorities [15:59] wrtp: Yes [16:00] niemeyer: so the latter cert goes in the cloud-init data, right? [16:01] wrtp: Yes, we have to send the private key and the public key for the server in cloud-init [16:02] niemeyer: it's more than just the public key - it's the *certificate* (which includes expiry time, possible server name etc) too, right? [16:02] wrtp: We can call it shit if you want.. [16:02] wrtp: Sorry.. I'm getting slightly tired by now [16:02] niemeyer: i'm sorry, that's a big difference [16:03] niemeyer: because a certificate is valid for a while [16:03] niemeyer: so even if we change the private key, that certificate will still be valid [16:03] niemeyer: so we *could* make the expiry time short [16:03]