Hide Forgot
I can't seem to get to the staging docs right now, so it'll be a bit hard to describe where to put this. I know we have a section covering the creation of SSL certificates and I think it'd make sense to stuff in there. To reiterate something I've said before, I hate that section. We don't want to be in the business of telling people how to configure security; they should have their own people for that. That said, I think this is an important note that their security people will want to see. It's sort of a situation where a skilled security dude will want to glance at this section and know this sort of thing, but then won't care about all of the instructional fluff for noobs we provide after it. "It is recommended that a different CA certificate be used to sign the SSL certificates v. the client entitlement certificates." That right there is a dense statement. There's a lot I could elaborate on, but frankly, I don't want to. We could talk about using a single CA with child trusted CAs or mention the reasons they'd want to. But again, that's not what we're selling here IMO. So don't think I'm being lazy in that description, it's just the level of depth I explicitly want to aim for (feel free to rub some grammar on it though, there has to be a better way of saying that than using "v."). Now, if they do choose to use the same CA certificate, there's something they'll need to know. "If the same CA certificate is used to sign both server-side SSL certificates and client-side entitlement certificates, the serial numbers for all server-side SSL certificates must all be below 0100." That's the big important note their security dude should see and be like "Ok, good to know." Here's why: * Serial numbers must be unique across all certificates signed by that CA. * RHUI Manager will automatically assign serial numbers to entitlement certificates it creates. * Those serial numbers RHUI Manager assigns start at 0100 and increment from there (the next is 0101, 0102, and so on). * We require the customer to create the server-side SSL certificates on their own, so they have to be sure to not overlap and use a serial number that will then be used by RHUI Manager for an entitlement certificate. * Again, this is only relevant in the case where the same CA certificate is used. If a separate CA is used to sign the server-side SSL certificates, this is a non-issue. In case you're wondering, the leading zero is intentional. I tried just using "100" and I got an error that the value had an odd number of digits. True story; I'd never seen an error message like that before. How oddly specific. Also, above notice I took the example out to 0102. The intent there was in case the customer tries to be smart and think these numbers are binary, the 0102 example should show they aren't. I know there's a section on that page where we provide sample code on how to sign a certificate. We tell them how to create the .srl file and we tell them to default it to 01 (something like "echo 01 > foo.srl"). Let's change that to 10 instead of 01 for my own sanity. That still gives them 90 serial numbers with that CA certificate before they drift into entitlement manager territory.
(In reply to comment #0) > I can't seem to get to the staging docs right now, so it'll be a bit hard to > describe where to put this. I know we have a section covering the creation of > SSL certificates and I think it'd make sense to stuff in there. > > To reiterate something I've said before, I hate that section. We don't want to > be in the business of telling people how to configure security; they should > have their own people for that. That said, I think this is an important note > that their security people will want to see. It's sort of a situation where a > skilled security dude will want to glance at this section and know this sort of > thing, but then won't care about all of the instructional fluff for noobs we > provide after it. > > "It is recommended that a different CA certificate be used to sign the SSL > certificates v. the client entitlement certificates." > > That right there is a dense statement. There's a lot I could elaborate on, but > frankly, I don't want to. We could talk about using a single CA with child > trusted CAs or mention the reasons they'd want to. But again, that's not what > we're selling here IMO. So don't think I'm being lazy in that description, it's > just the level of depth I explicitly want to aim for (feel free to rub some > grammar on it though, there has to be a better way of saying that than using > "v."). > > Now, if they do choose to use the same CA certificate, there's something > they'll need to know. > > "If the same CA certificate is used to sign both server-side SSL certificates > and client-side entitlement certificates, the serial numbers for all > server-side SSL certificates must all be below 0100." > > That's the big important note their security dude should see and be like "Ok, > good to know." Here's why: > > * Serial numbers must be unique across all certificates signed by that CA. > * RHUI Manager will automatically assign serial numbers to entitlement > certificates it creates. > * Those serial numbers RHUI Manager assigns start at 0100 and increment from > there (the next is 0101, 0102, and so on). > * We require the customer to create the server-side SSL certificates on their > own, so they have to be sure to not overlap and use a serial number that will > then be used by RHUI Manager for an entitlement certificate. > * Again, this is only relevant in the case where the same CA certificate is > used. If a separate CA is used to sign the server-side SSL certificates, this > is a non-issue. > > In case you're wondering, the leading zero is intentional. I tried just using > "100" and I got an error that the value had an odd number of digits. True > story; I'd never seen an error message like that before. How oddly specific. > Also, above notice I took the example out to 0102. The intent there was in case > the customer tries to be smart and think these numbers are binary, the 0102 > example should show they aren't. Added at the beginning of the section: <para> In order to use &RHUI; you will need to purchase a root SSL certificate and a private key, and be able generate SSL certificates of your own. This section outlines the basic skills you require to be able to perform these tasks. </para> <note> <title>Note</title> <para> It is recommended that you sign the SSL certificates and the client entitlement certificates with different certificate authorities (CAs). However, if you choose to use the same CA to sign both certificates, ensure the serial numbers for all server-side SSL certificates are below <parameter>0100</parameter> to avoid conflicts within &RHUI;. </para> </note> I haven't gone into any real detail here, for the same reasons Jay gave above. Happy to edit if required, though. > > I know there's a section on that page where we provide sample code on how to > sign a certificate. We tell them how to create the .srl file and we tell them > to default it to 01 (something like "echo 01 > foo.srl"). Let's change that to > 10 instead of 01 for my own sanity. That still gives them 90 serial numbers > with that CA certificate before they drift into entitlement manager territory. <step> <para> Create a file with the same name and in the same location as the CA certificate you have but using a <filename>.srl</filename> extension. The file should contain the text <parameter>10</parameter> only. This can be performed using the following command: </para> <screen> $ echo 10 > <replaceable>/home/example/certs/ca.srl</replaceable></screen> </step> Revision 1-24 (and we've fixed the problem on the stage, too. You should be able to see this within the hour). LKB
This book is now available at http://docs.redhat.com/docs/en-US/Red_Hat_Update_Infrastructure/2.0/html/Installation_Guide/index.html Please raise a new bug for any further changes. LKB