[StyleSheet]\n[SiteTitle]\n[SiteSubtitle]\n[SideBarOptions]
~IPfonix, Inc. KDC Configuration
TiddlyWikis are self-contained microcontent management files. More information can be found at [[www.tiddlywiki.com|http://www.tiddlywiki.com]].
Modern cryptography may be divided into two branches: Symmetric Key Cryptography and [[Public Key Cryptography]].\n\nSymmetric Key Cryptography is the kind of classical cryptography with which we are most familiar. Algorithms based on symetric keys may be used to encrypt information between two parties who share a key. Once a message has been encrypted with a key K, the message can only be decrypted by someone with access to the same key. Therefore, in order to keep encryped messages secret, it is important that only the originator and intended recipient of the message have access to the key K.\n\nSince the same K is used for both encryption and decryption, this system is called Symmetric Key Cryptography, to differentiate it from systems that use distinct encryption and decryption keys.\n\nSymmetric keys may be long-lived, in which case they are termed "service keys", or intended for short term use within a single application session, in which case they are termed "session keys". Often (although not always) session keys are derived by applying an algorithm to long-lived service keys. They may also be created on-the-fly within the session in which they are to be used. Sesison keys are discarded at the end of the session.\n
Public Keys are used in [[Public Key Cryptography]].
Modern cryptography may be divided into two branches: [[Symmetric Key Cryptography]] and Public Key Cryptography.\n\nPublic Key Cryptography is an advance dating from the 1970s that revolutionized cryptography. Prior to the invention of Public Key Cryptography, all systems were based on the use of symmetric keys.\n\nIn Public Key cryptographic systems, two distinct keys are used: a [[Private Key]] and a [[Public Key]]. \n\n
A [[Private Key]] and its matching [[Public Key]]. Generally, the information contained in a Public Key is a subset of the information in a Private Key.
Strictly speaking, any key that must be kept secret in order to maintain the secrecy of a message. In this sense, any symmetric key is also a private key.\n\nMore commonly, the portion of a public/private [[Key Pair]] that must be kept secret.\n\nIn public key cryptosystems that support both encryption and signatures (such as [[RSA]]), the private key is used to decrypt encrypted messages and to sign signed messages.
A public key is one part of a [[Key Pair]] (the other part is a [[Private Key]]). A public key does not have to kept secret. In fact, it should be completely open to the public.\n\nIn public key cryptosystems that support both encryption and signatures (such as [[RSA]]), the public key is used to encrypt messages and to verify signed messages.
A self-signed certificate is one that is signed by the [[Private Key]] that corresponds to the [[Public Key]] encapsulated within the certificate. In other words, the Public Key in the certificate and the Private Key that sign the certificate form a [[Key Pair]].\n\nSelf-signed certificates are used as root certificates in a certificate hierarchy.\n
A series of certificates in which the [[Private Key]] of certificate //N// signs certificate //N+1//.
A Root Certificate is one that is [[self-signed|Self-signed certificates]]. That is, the [[Private Key]] that signs the certificate forms a [[Key Pair]] with the [[Public Key]] that is encapsulated by the certificate.
Certificates are used in hierarchies that chain from one certificate to the next. Certificate hierarchies work like this:\n\n* At the root of a hierarchy is a [[root certificate|Root Certificates]], C~~0~~. A root certificate is [[self-signed|Self-signed certificates]]. An example of a root certificate is the Service Provider Root certificate. We will call the [[Public Key]] in the root certificate Pu~~0~~, and the corresponding [[Private Key]] (which signs the certificate and forms a [[Key Pair]] with the [[Public Key]]), Pr~~0~~.\n* A second certificate, C~~1~~ is created, encapsulating a different [[Public Key]], Pu~~1~~. This certificate is signed by Pr~~0~~. Because of the relationship between the [[Public Key]] in the root cretificate and the signature on the second certificate, these two certificates are said to chain. An example of such a certificate is the Service Provider certificate. C~~1~~ is often said to be "signed by" C~~0~~, although in fact it is signed by the [[Private Key]] that forms a [[Key Pair]] with the [[Public Key]] in C~~0~~.\n\nThis process can be extended as many times as necessary. So we could create a third certificate, C~~2~~ (for example, a Local System certificate), that encapsulates yet another [[Public Key]], Pu~~2~~ and is signed by Pr~~1~~. Similarly, a KDC certificate, C~~3~~, encapsulates Pu~~3~~ and is signed by Pr~~2~~. (Note: The Local System certificate is optional; if it is not present, then the KDC certificate is signed directly by the Service Provider certificate).\n\nSo the end result is an entire [[chain|Certificate chain]] of certificates, in which the certificate that encapsulates Pu~~n~~ is signed by Pr~~n-1~~, except that the certificate that encapsulates Pu~~0~~ is signed by Pr~~0~~ (which also signs the certificate that encapsulates Pu~~1~~). \n\nAn example of such a chain is the set of certificates: Service Provider Root, Service Provider, Local System, KDC. Because of the relationships among the various keys, this chain can be interpreted to mean:\n# C~~0~~: I am the Service Provider Root certificate. My Public Key is Pu~~0~~. I'm not telling you my Private Key, but you know I have access to Pr~~0~~, because I have signed myself. You can verify the signature by checking it with the value of Pu~~0~~ that I contain.\n# C~~1~~: I am the Service Provider certificate. My Public Key is Pu~~1~~. You don't have to believe me, though. The certificate that signed me is C~~0~~. Go ahead and verify the signature on me by using Pu~~0~~. You will find that it verifies correctly. That means that only someone with access to Pr~~0~~ can have signed me, and the only entity with that access is the entity that created C~~0~~. In plain English, this means that the entity that created C~~0~~ is guaranteeing that I am a Service Provider certificate, and I belong to the Service Provider that is named inside me.\n# C~~2~~: I am a Local System certificate. My Public Key is Pu~~2~~. You don't have to believe me, though. The certificate that signed me is C~~1~~. Go ahead and verify the signature on me by using Pu~~1~~. You will find that it verifies correctly. That means that only someone with access to Pr~~1~~ can have signed me. That entity is the Service Provider named in C~~1~~, which is therefore guaranteeing that I am for a Local System operated by that Service Provider.\n# C~~3~~: I am a KDC certificate. My Public Key is Pu~~3~~. You don't have to believe me, though. The certificate that signed me is C~~2~~. Go ahead and verify the signature on me by using Pu~~2~~. You will find that it verifies correctly. That means that only someone with access to Pr~~2~~ can have signed me. That entity is the Local System named in C~~2~~, which is therefore guaranteeing that I am for a KDC operated within that Local System.\n\nA device that receives a message that contains all these certificates can therefore follow a chain of trust by verifying the various signatures, and can conclude that:\n# The Service Provider Root guarantees that the Service Provider Public Key is correct;\n# The Service Provider guarantees that the Local System Public Key is correct;\n# The Local System guarantees that the KDC Public Key is correct.\n\nTherefore, the recipient is assured that the KDC public key encapsulated in the KDC certificate truly belongs to the KDC. It may therefore safely verify messages signed by that key, or may encrypt messages with that key.\n\nYou may have noticed a weakness in the chain described above. Who is to say that C~~0~~ really belongs to someone trustworthy? A device could create a Key Pair, use those to generate a C~~0~~, and then create an entire chain that would verify correctly, but which would be completely untrustworthy.\n\nThis is thwarted by requiring that the recipient device hold a copy of C~~0~~ ahead of time. In other words, the root certificate must be pre-provisioned on to the recipient device. And since the recipient device already has C~~0~~, that certificate is usually omitted from the transmitted chain. (And if it is not omitted, the recipient decvice must check that the recieved C~~0~~ is identical to the provisioned C~~0~~ -- or at the very least, it must check that the the value of Pu~~0~~ is the same for the two certificates.)\n\nSo, to give a concrete example from ~PacketCable, there are two independent certificate hierarchies: a Manufacturer hierarchy and a Service Provider hierarchy. The complete Manufacturer hierarchy contains three certificates: \n#MTA Root\n#MTA Manufacturer\n#MTA device. \n\nThe complete Service Provider hierarchy contains four certificates:\n#Service Provider Root\n#Service Provider\n#Local System (optional)\n#KDC.\n\nIn its request, the MTA sends the MTA Manufacturer and MTA device certificate to the KDC. The KDC authenticates these by checking against the provisioned MTA Root. In its reply, the KDC sends the Service Provider, Local System and KDC certificates. The MTA authenticates these by checking against the provisioned Service Provider Root. Since the MTA is not intended to be easily programmed, the Service Provider Root cert is burned into the MTA at the time of manufacture (along with the MTA Manufacturer and MTA device certificates).\n
http://www.ipfonix.com/
This TiddlyWiki is designed to help new customers configure an [[IPfonix, Inc.|http://www.ipfonix.com]] KDC.\n\nIt provides details of the configuration of certificates and keys, and is designed to augment the information in the KDC User Guide that is supplied with the KDC software, in order to assist customers who are unfamiliar with managing certificates and keys.\n\nThis document does not descibe the various {{{@@color(black):kdc.ini@@}}} file options that you may need to tailor the behaviour of the KDC to your particular environment. The details of the many {{{@@color(black):kdc.ini@@}}} configuration parameters are contained in your KDC User Guide.
config.options.chkHttpReadOnly = true;\n
RSA is a widely used public key cryptosystem. All the certificates used in ~CableLabs and tComLabs specifications are required to contain an RSA [[Public Key]].
Certificates are placed in directories that lie under the {{{@@color(black):.../packetcable/@@}}} or {{{@@color(black):.../cablehome/@@}}} directory. The directories that hold certificates MUST have names that begin with the string: {{{@@color(black):certificates@@}}}. For example, an operator who wished to support both ~PacketCable and ~EuroPacketCable certificate hierarchies might have two directories, {{{@@color(black):.../packetcable/certificates-pc@@}}} and {{{@@color(black):.../packetcable/certificates-epc@@}}} for the two sets of certificates.\n\nThese directories are used to store several X.509 certificates in standard ~DER-encoded binary format, along with the KDC [[Private Key]]. \n\nAt start-up, the KDC separately examines every directory of the form {{{@@color(black):.../packetcable/certificates*@@}}}, and checks the contents for validity. (See the [[Certificate Rules]] for the relationships that must exist among the certificates.)\n\nInside each directory, certificate files may have any name, but each must end with the file extension {{{@@color(black):.cer@@}}}. The KDC will automatically determine which certificate is which.\n\nFor ~PacketCable and ~EuroPacketCable, the directory must contain certificates corresponding to the Service Provider Root, the Service Provider, the KDC and the MTA Root. It may also optionally contain a Local System certificate. \n\nFor ~CableHome, the directory must contain certificates corresponding to the Service Provider Root, the Service Provider, the KDC and the Manufacturer Root. It may also optionally contain a Local System certificate. \n\nEach certificate directory is treated completely independently of the others, except that the public keys of the client root certificates must all be unique. (This is to ensure that, when the KDC receives an ~AS-REQ message from a client, it can correctly determine which set of certificates is to be used to generate the reply.)\n\nIn addition to the certificates themselves, each directory must contain the [[RSA]] [[Private Key]] that corresponds to the KDC certificate in the directory. This is needed so that the KDC can correctly sign ~AS-REP messages. \n\nThe KDC looks for the key in a file named {{{@@color(black):~KDC_private_key@@}}}.\n\nThere are several formats commonly used to transfer [[RSA]] private keys keys among systems. The KDC allows you to use PKCS#8, PKCS#1 or a proprietary format that is described in the KDC User Guide. If you use one of the PKCS formats, the file MUST contain the //binary// information ''exactly as defined by the relevant PKCS specification''. Files that contain only ASCII text are non-conformant, and will not be accepted by the KDC. If you use a key-generating program that creates keys in an ASCII format, those keys must be converted to a standards-conformant format before they can be loaded on the KDC.\n
The KDC software package includes one or more sets of example certificates. (There are separate sets for ~PacketCable, ~Euro-PacketCable and ~CableHome.)\n\nEach set of example certificates fully conforms to the relevant security specification. However, it is important to realise that, depending on your purposes, mere conformance to the specifications is insufficient to guarantee a working client/server system. In a working system, not only must the certificates conform to the specification, but they must also fulfil a set of [[Certificate Rules]]. The Certificate Rules may divided into three categories:\n# Rules that certificates on the KDC MUST follow:\n## The Service Provider MUST be signed by the Service Provider Root\n## The Local System (if present) MUST be signed by the Service Provider\n## The KDC MUST be signed by the Local System (if present, or the Service Provider if there is no Local System).\n# Rules that certificates on the client MUST follow:\n## The client Device MUST be signed by the client Manufacturer\n# Rules that control the relationship between the certificates on the client and those on the KDC.\n## The client Manufacturer MUST be signed by the client Root that is on the KDC\n##The Service Provider Root on the KDC MUST be identical to the Service Provider Root on the client\n\nSo it is insufficient simply to take the example certificates and to install them on the KDC -- doing this addresses only one of the two devices. The certificates on the client MUST also follow the above rules. In the case where the customer completely controls the operation of the client (such as, for example, when the customer is an MTA vendor), then it is relatively easy to create conformant device certificates that are consistent with the example certificates, and to load them on to the client device. However, if the customer has no capability to change the certificates on the client, then the customer MUST create new conformant certificates that are consistent with the client device certificates (//i.e.//, certificates that conform to the specification AND completely follow the [[Certificate Rules]], and load them on to the KDC. \n
[[About this page]]\n[[Certificates]]\n[[Service Keys]]\n\nContents of this [[TiddlyWiki|http://www.tiddlywiki.com]] are \n© [[IPfonix, Inc.|http://www.ipfonix.com]]\n\n<<newTiddler>>\n<<newJournal "DD MMM YYYY">>
Service Keys are long-lived keys that are shared between the KDC and an Application Server. The KDC supports all Application Servers defined by the ~PacketCable and ~CableHome specifications. These include, for example, devices such as Cable Modem Termination Systems, Wiretap Delivery Functions, Provisioning Servers and many more.\n\nService Keys may be configured on to the KDC either automatically, using the Dynamic Service Key mechanism defined in the KDC User Guide, or manually. Here we discuss only manual configuration.\n\nService keys are contained in files contained in the {{{@@color(black):.../keys/@@}}} subdirectory of the KDC directory hierarchy. Each file in that directory contains a single key.\n\n[[Service Key File Names]] describes how to map the name of a service to a filename.\n[[Service Key Files|Contents of Service Key Files]] describes the contents of the service key files.\n\n
The actual service keys are contained in the service key files. The service keys are unencrypted, since it is assumed that only administrators with full access will be permitted to read the files in the service key directory.\n\nA service key file contains ''exactly 26 octets''. If the length of the file is incorrect, the KDC will refuse to load the file. The 26 octets are broken down as follows:\n#The first two octets are a key version number\n# The last 24 octets are the actual 3DES service key\n\nThe KDC obtains the key version number by reading the first two octets and interpreting them as an unsigned 16-bit integer, in network octet order. So, for example, the simple case where the first two octets are 0x0000 corresponds to key version number 0; the value 0x0123 correspondes to key version number 291, and so on.\n\nThe last 24 octets can have any value (with a few exceptions, because the KDC will not accept DES weak or semi-weak keys). In a test lab, it is usually convenient to open an editor and create a file that contains exactly 26 octets; it does not matter that the key in this case will contain 24 ASCII characters -- it is still a valid key.\n\nSo, for example, in a test environment we often use a service key file that contains the 26 ASCII characters:\n{{{@@color(black):00123456789012345678901234@@}}}\nThe key version is therefore 0x3030, which corresponds to version number 12336, and the actual service key is 0x313233343536373839303132333435363738393031323334\n\nA word about DES parity: the KDC follows the FIPS reccomendations in that it accepts keys with incorrect parity, but will produce keys with correct parity.
The file names in the {{{@@color(black):.../keys/@@}}} directory are important. The name of a file encodes the identity of the server that uses the key contained in the file.\n\nIn Kerberos, names of services are known as Principal Identifiers, and are written in the form aaa/bbb/ccc...nnn@REALM. The ~PacketCable and ~CableHome specifications define the values of the components before the @ sign that apply for each particular kind of server. For example, an MTA is defined to be identified by a Principal Identifier of the form: mta/<FQDN>@REALM. Such strings cannot be used as file names, because the slash character is not permitted in a filename. Consequently, the filenames that contain service keys modify the Principal Identifier slightly, by replacing any slashes by commas. So an MTA service key filename has the form: mta,<FQDN>@REALM. For example, mta,mta.ipfonix.com@IPFONIX.COM is a valid name for a service key file.\n
\n.title { \n background-color: #99aaee; \n font-weight: bold;\n}\n\n#displayArea {\n background-color: #aaffaa; \n margin-top: 0;\n margin-left: 12%;\n width: 70%;\n} \n\n/* The Main Manu */\n#mainMenu \n{ border: 0px solid #ffff88; \n width: 10%;\n}\n\n#commandPanel {background-color: #ff8800; }\n\n/* TiddlyWiki title */\n#titleLine{\n color: #22cc22;\n background: #f0f0f0;\n border: 1px;\n padding: 0;\n text-align: center;\n height: 46px;\n font-weight: bold;\n}\n\n/* TiddlyWikis in the title */\n#contentWrapper #siteTitle a{\n color: #22cc22;\n}\n\n/* Message that says that the TiddlyWiki has been saved */\n#messageArea{\n position: fixed;\n top: 0;\n right: 0;\n font-size: 10px;\n border: 1px solid #aaa;\n background-color: #aaffaa; \n z-index: 25;\n}\n\n/* Entire panel where search and options appear */\n#sidebar{\n font-family: sans-serif;\n top:46px;\n}\n\n/* The options portion of the sidebar */\n#sidebarOptions{\n background: #aaa;\n right: 0;\n margin-top: 0;\n width: 100%;\n}\n\n#contentWrapper #sidebarOptions .button{\n color:#002bb8;\n padding: .1em 0 .1em 2em;\n}\n\n/* The Advanced Options portion of the sidebar */\n#sidebar .sliderPanel{\n background: #e9e9e9;\n}\n\n#sidebar .sliderPanel input{width: auto;}\n\n/* The tabs portion of the sidebar */\n#sidebarTabs{\n background: #fff;\n margin-top: 0;\n width: 100%;\n}\n\n#sidebarTabs{\n background: #666;\n color: #ff0000; /* headings in, for example, Timeline */\n text-decoration: none;\n}\n\n#sidebarTabs .tabContents,#sidebarTabs .tabContents .tabContents{\n /* border: 1px solid #aaa; */\n background: #aaa;\n}\n\n/* Links in the drop-downs from the tabs */\n#contentWrapper #sidebarTabs .tiddlyLink,\n#contentWrapper #sidebarTabs .button,\n#contentWrapper #sidebarTabs a.tiddlyLink:hover,\n#contentWrapper #sidebarTabs a.button:hover{\n background: transparent;\n color: #002bb8;\n}\n\n/* Dunno what these are */\n/*\n#popup{\n background: #e9e9e9;\n color: #000;\n}\n\n#contentWrapper{\n color:#002bb8;\n padding: 0;\n margin: 0;\n background: transparent;\n}\n\n*/\n
!Certificate Rules for ~PacketCable and ~EuroPacketCable\n\nA. On the ~MTAs, there are three certificates:\n* a Service Provider Root\n* a MTA Manufacturer\n* a Device\n\nB. On the KDC there are five certificates:\n* an MTA Root (called the "~Euro-PacketCable Root Certificate" in ~EuroPacketCable)\n* a Service Provider Root\n* a Service Provider\n* a Local System (this one actually is optional, but we assume that you will use it)\n* a KDC\n\nC. ''The following MUST all be true:''\n# The MTA Manufacturer MUST be signed by the MTA Root\n# The MTA Device MUST be signed by the MTA Manufacturer\n# The Service Provider Root on the KDC MUST be identical to the Service Provider Root on the MTA\n# The Service Provider MUST be signed by the Service Provider Root\n# The Local System (if present) MUST be signed by the Service Provider\n# The KDC MUST be signed by the Local System (if present, or the Service Provider if there is no Local System).\n\nIf ''any'' of those is not true, it represents a possible security hole and the KDC will not grant a ticket to the MTA. \n\nThese rules are not confined to ~IPfonix ~KDCs; they are the rules that any KDC must follow in order not to open a security hole.\n\nThe KDC can perform checks 4, 5, and 6 at start-up, and will refuse to start if the certificates fail those tests. Tests 1 and 2 can only be applied at the time that the KDC receives a request from an MTA. The KDC cannot perform test 3 at all; only the MTA can perform that test. If the KDC generates an ~AS-REP but the MTA refuses to accept the ~AS-REP, it almost certain that the reason is that the MTA is executing test 3 and finding that the Service Provider certificate in the ~AS-REP does not chain properly to the Service Provider Root on the MTA. If this is happening then you must either:\n# Replace the Service Provider Root certificate in the MTA with the one that is on the KDC; or\n# Create an entire new Service Provider chain based on the Service Provider Root on the MTA, and then load this new chain on to the KDC.\n\n\n!Certificate Rules for ~CableHome\n\nA. On the PS Element devices, there are three certificates:\n* a Service Provider Root\n* a Manufacturer\n* a PS Element\n\nB. On the KDC there are five certificates:\n* a Manufacturer Root\n* a Service Provider Root\n* a Service Provider\n* a Local System (this one actually is optional, but I assume that you will use it)\n* a KDC\n\nC. ''The following MUST all be true:''\n# The Manufacturer MUST be signed by the Manufacturer Root\n# The PS Element MUST be signed by the Manufacturer\n# The Service Provider Root on the KDC MUST be identical to the Service Provider Root on the PS Element device\n# The Service Provider MUST be signed by the Service Provider Root\n# The Local System (if present) MUST be signed by the Service Provider\n# The KDC MUST be signed by the Local System (if present, or the Service Provider if there is no Local System).\n\nIf ''any'' of those is not true, it represents a possible security hole and the KDC will not grant a ticket to the PS Element device. \n\nThese rules are not confined to ~IPfonix ~KDCs; they are the rules that any KDC must follow in order not to open a security hole.\n\nThe KDC can perform checks 4, 5, and 6 at start-up, and will refuse to start if the certificates fail those tests. Tests 1 and 2 can only be applied at the time that the KDC receives a request from a PS Element device. The KDC cannot perform test 3 at all; only the PS Element device can perform that test. If the KDC generates an ~AS-REP but the PS Element device refuses to accept the ~AS-REP, it almost certain that the reason is that the PS Element device is executing test 3 and finding that the Service Provider certificate in the ~AS-REP does not chain properly to the Service Provider Root on the device. If this is happening then you must either:\n# Replace the Service Provider Root certificate in the PS Element with the one that is on the KDC; or\n# Create an entire new Service Provider chain based on the Service Provider Root on the PS Element device, and then load this new chain on to the KDC.\n
As described in the [[Certificate Rules]]: \n\nA. On the ~MTAs, there are three certificates:\n* a Service Provider Root\n* a MTA Manufacturer\n* a Device\n\nB. On the KDC there are five certificates:\n* an MTA Root (called the "~Euro-PacketCable Root Certificate" in ~EuroPacketCable)\n* a Service Provider Root\n* a Service Provider\n* a Local System (this one actually is optional, but we assume that you will use it)\n* a KDC\n\nC. ''The following MUST all be true:''\n# The MTA Manufacturer MUST be signed by the MTA Root\n# The MTA Device MUST be signed by the MTA Manufacturer\n# The Service Provider Root on the KDC MUST be identical to the Service Provider Root on the MTA\n# The Service Provider MUST be signed by the Service Provider Root\n# The Local System (if present) MUST be signed by the Service Provider\n# The KDC MUST be signed by the Local System (if present, or the Service Provider if there is no Local System).\n\nWhen having certificate problems, it is sometimes helpful to know exactly when each of the six tests enumerated above is performed.\n\nTests 4, 5 and 6 are all performed at startup time on the KDC. So if the KDC successfully starts, then those three tests have been passed.\n\nThe KDC performs tests 1 and 2, in that order, when it receives the ~AS-REQ from the MTA. Since test 2 can only be failed if the MTA is buggy, then it is almost guaranteed that test 2 will be passed; so if the KDC complains about certificates after receiving an ~AS-REQ, then it is almost certainly because test 1 is not being passed.\n\nThe KDC cannot perform test 3. Only the MTA can perform that test, and it can do so only when it receives the ~AS-REP from the KDC. If the MTA appears to go into an endless loop of sending ~AS-REQ messages and receiving ~AS-REPs from the KDC, then almost certainly the problem is that test 3 is not being passed (this can be hard to verify directly, since typically ~MTAs do not provide good error diagnostics; however, our experience is that such behaviour is almost always caused by certificates that fail test 3).
Certificates are files that encapsulate [[Public Keys]].\n\nIn addition to the basic public key information, certificates encode ancillary information that includes at least:\n* A validity period\n* Name of issuer\n* Serial number\n* Digital signature using the [[Private Key]] of the issuer\n\nAs you can see from the last item in the list above, digital certificates are signed by the issuer. This ensures that they cannot be altered in any way, since any change will cause any attempt to verify the signature to fail.\n\n[[Certificate Theory]] describes the basic theory behind certificates.\n[[Certificate Rules]] describes the rules that apply to certificates used in ~PacketCable, ~EuroPacketCable and ~CableHome. ''If your configuration does not conform to these rules, either the KDC will refuse to start, or the client will reject messages from the KDC.''\n[[Certificate Checking]] describes when the various certificates are checked.\n[[Certificate Configuration]] describes how to configure certificates on an ~IPfonix, Inc. KDC. This is a slightly enhanced version of the text in the KDC User Guide.\n[[Example Certificates]] explains the example certificates that are provided with the KDC software, and describes why merely loading the certificates on to a KDC is not sufficient to guarantee a working client/server system.