HP 635n Practical IPsec Deployment for Printing and Imaging Devices - Page 107

HP Jetdirect and Public Key Certificates, IKE Authentication: Public Key Certificates, The Microsoft

Page 107 highlights

Public Key Infrastructure (PKI) that includes an entire policy around certificates. Because we are discussing IPsec for the Intranet, we will be talking about Microsoft's certificate authorities later on. HP Jetdirect and Public Key Certificates Now that we have covered some basics around certificates, we can talk specifically about Jetdirect. Jetdirect is an embedded system and as a result, has limited storage space for certificates. Jetdirect can store one Identity certificate and one CA certificate. The CA certificate tells Jetdirect which identity certificates should be trusted (i.e., must be signed by that CA) when Jetdirect is receiving a certificate from another entity. Jetdirect's Identity certificate is the certificate that is sent out when another entity requests it. It is important to note that the CA certificate on Jetdirect is configured strictly to provide the trust point for identity certificates that are sent to Jetdirect - the identity certificates received from other entities must be signed by that CA. Since Jetdirect only has one Identity certificate that can be configured, it must be capable of being used in a variety of situations. Jetdirect can act as a client or a server, depending on the protocol being used. For instance, if a web browser is using HTTPS to communicate to Jetdirect, Jetdirect will return its Identity certificate as part of the SSL/TLS negotiation process. In other cases, like LDAPS, Jetdirect will send its Identity certificate for client authentication if required. We do not want to install a Jetdirect Identity certificate that works for IPsec but fails for SSL/TLS. In this whitepaper, we will cover how to create a Jetdirect certificate with the proper attributes to satisfy all the protocols. By default, Jetdirect will create a "self-signed" certificate the first time it is powered on. This certificate is not secure because it has not been signed by a trusted CA. An important step in the security of a Jetdirect product is to replace the default self-signed Identity certificate with one that has been signed by a trusted CA. IKE Authentication: Public Key Certificates How does IPsec use certificates? Well, these certificates only come into play during IKE negotiation and specifically they only affect the Authentication phase in IKE Phase 1. All other things we discussed about IPsec remain the same. During the authentication phase, these public key certificates are exchanged. The following items are verified: • Is the certificate signed by the configured CA? • Does the certificate holder posses the corresponding private key for that certificate? If each certificate passes these tests, then authentication is successful. Otherwise, IKE phase 1 doesn't pass and IPsec communication cannot happen. The Microsoft Certificate Authority Environment Microsoft has an "Enterprise CA" and a "Standalone CA". The Enterprise CA is pretty common among the environments that would potentially use IPsec. Therefore, this whitepaper will focus on the enterprise CA. In order to ensure that the Jetdirect certificates are created correctly, we will need to create a Certificate Template. A certificate template is the guide that controls how the certificates are created. 107

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
  • 172
  • 173
  • 174
  • 175
  • 176
  • 177
  • 178
  • 179
  • 180
  • 181
  • 182
  • 183
  • 184
  • 185
  • 186
  • 187
  • 188
  • 189
  • 190
  • 191
  • 192
  • 193

107
Public Key Infrastructure (PKI) that includes an entire policy around certificates.
Because we are
discussing IPsec for the Intranet, we will be talking about Microsoft’s certificate authorities later on.
HP Jetdirect and Public Key Certificates
Now that we have covered some basics around certificates, we can talk specifically about Jetdirect.
Jetdirect is an embedded system and as a result, has limited storage space for certificates.
Jetdirect
can store one Identity certificate and one CA certificate.
The CA certificate tells Jetdirect which
identity certificates should be trusted (i.e., must be signed by that CA) when Jetdirect is receiving a
certificate from another entity.
Jetdirect’s Identity certificate is the certificate that is sent out when
another entity requests it. It is important to note that the CA certificate on Jetdirect is configured strictly
to provide the trust point for identity certificates that are sent to Jetdirect – the identity certificates
received from other entities must be signed by that CA.
Since Jetdirect only has one Identity certificate that can be configured, it must be capable of being
used in a variety of situations.
Jetdirect can act as a client or a server, depending on the protocol
being used.
For instance, if a web browser is using HTTPS to communicate to Jetdirect, Jetdirect will
return its Identity certificate as part of the SSL/TLS negotiation process.
In other cases, like LDAPS,
Jetdirect will send its Identity certificate for client authentication if required.
We do not want to install
a Jetdirect Identity certificate that works for IPsec but fails for SSL/TLS. In this whitepaper, we will
cover how to create a Jetdirect certificate with the proper attributes to satisfy all the protocols.
By default, Jetdirect will create a “self-signed” certificate the first time it is powered on.
This certificate
is not secure because it has not been signed by a trusted CA.
An important step in the security of a
Jetdirect product is to replace the default self-signed Identity certificate with one that has been signed
by a trusted CA.
IKE Authentication: Public Key Certificates
How does IPsec use certificates?
Well, these certificates only come into play during IKE negotiation
and specifically they only affect the Authentication phase in IKE Phase 1.
All other things we
discussed about IPsec remain the same.
During the authentication phase, these public key certificates are exchanged.
The following items are
verified:
Is the certificate signed by the configured CA?
Does the certificate holder posses the corresponding private key for that certificate?
If each certificate passes these tests, then authentication is successful.
Otherwise, IKE phase 1 doesn’t
pass and IPsec communication cannot happen.
The Microsoft Certificate Authority Environment
Microsoft has an “Enterprise CA” and a “Standalone CA”.
The Enterprise CA is pretty common
among the environments that would potentially use IPsec.
Therefore, this whitepaper will focus on the
enterprise CA.
In order to ensure that the Jetdirect certificates are created correctly, we will need to create a
Certificate Template.
A certificate template is the guide that controls how the certificates are created.