krill
krill copied to clipboard
set of questions and issues regarding Krill Testbed Environment
Hello,
I am trying to create a comprehensive self hosted Krill Testbed environment using the steps in the official documentation. I want to set up child CAs for the out-of-the-box CA testbed via CLI, assign to this child CA a subset of the resources from the parent CA and initialize a new publisher with a different domain name for the new child CA. All of this with one Krill instance running in Testbed mode.
However, I don't seem to be able to do all of the above: can't successfully assign resources to children and assign/initialize a unique new publisher for each CA. I am using Krill 0.9.2 on Ubuntu 18.04. The following is the set of commands and steps I am using to achieve all of the above (but does not work). Any suggestions as to what I am doing wrong here or what the correct steps are, would be appreciated:
- creating CA and adding it as a child to the
testbedparent:
$ krillc add --ca newca
$ krillc parents request --ca newca > newca_parent_request.xml
$ krillc children add --ca testbed --child newca --ipv4 "10.0.0.0/8" --ipv6 "2001:DB8::32/32" --asn "AS65000" --request newca_parent_request.xml > newca_parent_response.xml
$ krillc parents add --parent testbed --ca newca --response newca_parent_response.xml
after this point the newca does have testbed as parent but if I check it via krillc show --ca newca I see Total resources: <none> whereas after running krillc children info --child newca --ca testbed I get shown the resources I initially assigned resources: asn: AS65000, v4: 10.0.0.0/8, v6: 2001:db8::/32
As a follow up test I created another newca2 CA to assign as child of newca (same resources as newca) and I received the following error message Error: Child 'newca2' cannot have resources not held by CA 'newca'. How does newca have and not have those resources according to the different content querying methods? How do I permanently assign those resources to newca and make them heritable for newca2?
- connecting CA with repository and setting up a publisher
$ krillc repo request --ca newca > publisher_request_newca.xml $ krillc pubserver publishers add --publisher newca --request publisher_request_newca.xml
The publisher newca now exists but I never made the connection between CA newca and the new publisher explizit. How does the system assign the new publisher to CA newca? I couldnt find a command to explicitly make it happen, since the publisher can also have any arbitrary name.
In the meantime CA newca still does not have a repository connected.
$ krillc show --ca newca
Name: newca
No repository configured.
How do i connect newca to a repository? In the documentation the command krillc repo update is mentioned which seems to not be valid in 0.9.2
$ krillc repo update -h
error: Found argument 'update' which wasn't expected, or isn't valid in this context
USAGE:
krillc repo [SUBCOMMAND]
For more information try --help
- Note about the tutorial: The tutorial suggests using certbot for our https certificate however the certbot commands do not work with a domain that is not on DNS, so the locally defined domain whose traffic I direct to the Krill instance, does not qualify. I used openssl instead. Is this an oversight, or is there a way to use certbot for local domains that I am missing?
You are not seeing any resources for 'newca' because it will only request a certificate from its parent after you have also configured its repository. Otherwise it would not know which URIs to include in its certificate sign request.
Regarding configuration of the repository. It seems that we forgot to update the "Get Started" documentation to point to the current CLI command to configure the repository for a CA. Our apologies, and thank for raising this. We will fix this. The CLI command that you will want to use is documented here:
https://krill.docs.nlnetlabs.nl/en/stable/cli.html#krillc-repo-configure
Regarding certbot.. you can use any proxy and any TLS certificate you like. This is just an easy way to do, at least we think it is. If you are running a private testbed, which is not accessible publicly you could also skip the proxy and access Krill directly.
I noticed that there is one more thing that we should document in this regard. Please review the service_uri setting in your installation. The default for testbed will be to use localhost, and this is fine as long as you run everything in one instance. But if you need access from elsewhere then you will need to change this to a public URI. It would then be good to have a valid TLS certificate as well, but.. because the RPKI publication and provisioning (between parent and child CA) protocols use signed messages, it will accept self-signed certificates here.
Hello Tim,
Thank you for the information. I can now pass down resources to child CAs. I have one more question.
I have one local Krill instance and I want to simulate a delegated RPKI ecosystem where publishers have different RRDP/RSYNC domains. My current default service_uri is localhost:3000 (krill.conf setup is identical to the testbed tutorial, except for the initial domain which I changed to a simple krill1.com) and with the proxy I map "local" domain names to localhost:3000. What commands can I use to set up publishers with other rrdp/rsync domains (all domains redirect to https://localhost:3000/)? I tried to do so by manually changing the repository response domains but upon restart:
Nov 08 13:11:22 workspace krill[5123]: 2021-11-08 13:11:22 [INFO] Will re-sync all CAs with their parents and repository after startup
Nov 08 13:11:23 workspace krill[5123]: 2021-11-08 13:11:23 [WARN] Rejecting delta sent by: newca. Error was: Publishing (rsync://krill2.com/repo/newca/1/6ABBCEF243F1A95C5B4237F619F7A38434639BCE.crl) outside of jail URI (rsync://krill1.com/repo/newca/) is not allowed.
Nov 08 13:11:23 workspace krill[5123]: 2021-11-08 13:11:23 [ERROR] Could not synchronize CA 'newca' with its repository/-ies. Error: Got error reply: error reply including: error code: permission_failure, text: Client does not have permission to update this URI.
How do I give Krill permission to use domains outside of what is strictly defined in the configuration as long as they are resolved to localhost? Or can I configure multiple domains?
How do I give Krill permission to use domains outside of what is strictly defined in the configuration as long as they are resolved to localhost? Or can I configure multiple domains?
The krill publication server only supports the base URI it's configured with, by design.
If you really need to test you can set up multiple server instances each with their own base URI. You can migrate existing CAs from one repository to another using the CLI (and a key roll), as described here:
https://krill.docs.nlnetlabs.nl/en/0.9.2/advanced-ca.html#migrate-to-a-new-repository
Hello Tim, I am trying to do a migration in between krill instances over 2 different linux environments. My first question is, is the 24h waiting period necessary to be observed even in testing environments i.e. is it hardcoded that one must wait 24h? Or can we just ignore it when not in production? Does the original CA need to be in phase 3 to run krillc keyroll activate or do we do it in phase 2?
The following should be the order of commands for migration pieced together if Im not mistaken.
original krill instance:
krillc keyroll init --ca testca1
krillc repo request --ca testca1 > publisher_request.xml
destination krill instance
krillc pubserver publishers add --publisher testca1 --request publisher_request.xml > publisher_response.xml
original krill instance:
krillc repo configure --response publisher_response.xml ***
krillc keyroll activate --ca testca1
Second, I went so far as creating the RFC 8183 Publisher Request XML in the destination CA but it looks like this:
<repository_response xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/" version="1" publisher_handle="testca1" service_uri="https://127.0.0.1:3000/rfc8181/testca1/" sia_base="rsync://localhost:3000/repo/testca1/" rrdp_notification_uri="https://localhost:3000/rrdp/notification.xml">
<repository_bpki_ta>...</repository_bpki_ta>
</repository_response>
I don't understand how this is supposed to look like for an external Krill instance in testbed mode. The service_uri is going to be 127.0.0.1 for testbed mode of every Krill instance, which is identical to the URI of the original Krill instance. Even changing the port wouldnt help because 127.0.0.1 is localhost. As for sia_base and rrdp_notification_uri, would manually change them to the local IP of the linux container this instance of Krill runs on be the way?
***this command is in the docs but it is probably wrong/outdated, krillc repo configure doesnt have --request anymore but --response
Hello Tim, I am trying to do a migration in between krill instances over 2 different linux environments.
I am not sure what you are trying to do. Krill supports migrating a CA to use a new repository, but it does NOT support migrating one krill CA instance to another server.
My first question is, is the 24h waiting period necessary to be observed even in testing environments i.e. is it hardcoded that one must wait 24h? Or can we just ignore it when not in production? Does the original CA need to be in phase 3 to run krillc keyroll activate or do we do it in phase 2?
The following should be the order of commands for migration pieced together if Im not mistaken.
original krill instance:
krillc keyroll init --ca testca1 krillc repo request --ca testca1 > publisher_request.xml
The repository migration will initiate a key roll of its own and can only be started if there is no keyroll in progress. If you had started a keyroll (as above), then finish it first using krillc keyroll activate --ca testca1. You do not need to wait 24 hours.
destination krill instance
krillc pubserver publishers add --publisher testca1 --request publisher_request.xml > publisher_response.xml
So, by "destination" do you mean the new dedicated publication server? Please read about set up here.
If you were using the 'testbed' setup for this server then it's still useful to read this - to understand how the publication server works.
original krill instance:
krillc repo configure --response publisher_response.xml *** krillc keyroll activate --ca testca1
Well that should update your CA to use the new Publication Server, provided that a key roll was not in progress when you called krillc repo configure.
Second, I went so far as creating the RFC 8183 Publisher Request XML in the destination CA but it looks like this:
<repository_response xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/" version="1" publisher_handle="testca1" service_uri="https://127.0.0.1:3000/rfc8181/testca1/" sia_base="rsync://localhost:3000/repo/testca1/" rrdp_notification_uri="https://localhost:3000/rrdp/notification.xml"> <repository_bpki_ta>...</repository_bpki_ta> </repository_response>
This is not request, but a response from that server's publication server to "testca1" as a publisher. I.e. the publisher_response.xml I assume you were trying to use with krillc repo configure for "testca1".
I don't understand how this is supposed to look like for an external Krill instance in testbed mode. The
service_uriis going to be 127.0.0.1 for testbed mode of every Krill instance, which is identical to the URI of the original Krill instance. Even changing the port wouldnt help because 127.0.0.1 is localhost. As forsia_baseandrrdp_notification_uri, would manually change them to the local IP of the linux container this instance of Krill runs on be the way?
Do not change these things manually.
The "service_uri" follows the configuration set in your Publication Server krill.conf file. If it is using localhost, then please update it as described here.
The sia_base and rrdp_notification_uri in the response for a publisher will be relative to the base URI that were set when the publication server was initialised. See here for more information on changing the URIs for a running dedicated server.. in short you can 'clear' it if you remove all publihers, and initialise it again.
If you were using a 'testbed' server for this, then it would be easiest to re-do the testbed set up because it will have its own publishers (the test trust anchor and testbed CAs). If you don't want re-install from scratch then just remove the contents for the krill data directory for your testserver, and make sure that you use the public uris in config and start it again.
You can do another repository migration for your CA 'testca1', provided that there is no previous migration / key roll in progress. If there is the do krillc keyroll activate first, and then start the migration.
***this command is in the docs but it is probably wrong/outdated,
krillc repo configuredoesnt have--requestanymore but--response
Thanks for the pointer, this was correct in the CLI part of the documentation - but it was wrong in this migration guide.
I will close this issue for now. If you have any more questions or comments feel free to re-open or email [email protected]