HP Jetdirect 610n HP Jetdirect Print Servers - HP Jetdirect and SSL/TLS - Page 86

Match dNS Name

Get HP Jetdirect 610n PDF manuals and user guides View all HP Jetdirect 610n manuals
Add to My Manuals
Save this manual to your list of manuals

Page 86 highlights

Effectively, the algorithm is going to be something like this: If( dNSName is present) { Match dNS Name } Else { Match Common Name } For HTTPS, we saw that a mismatch caused a warning dialog box with Internet Explorer 6 and an explicit Certificate Error with Internet Explorer 7. Combining everything we have learned so far, we can form a very easy rule with SSL/TLS: One name to one IP Address to one port number identifies one certificate. For instance, looking at the previous trace: w2003.example.internal => 192.168.0.1 + TCP 636 => LDAPS certificate That was easy, right? Well, things get more complicated due to a few factors: • Server Farms - having multiple servers respond to one name • Virtual Hosting - having one web site for many customers • Limited IP addresses - public servers require public IP addresses • SSL Certificates for the Internet cost money Server farms are where I have several machines handling SSL requests in order to load balance. For example, if you do an nslookup on a major site, you may see more than one IP address. Going back to our LDAPS example, it would be something like this: w2003.example.internal = 192.168.0.1, 192.168.0.2, 192.168.0.3 Each time the name w2003.example.internal is resolved to an IP address, a different IP address is used. This behavior allows for load balancing. If each IP address is a separate machine, a single certificate needs to be stored on multiple machines because of how the naming checks are done. When distributing the same certificate to multiple machines, there is a danger around private key protection. Alternatively, separate certificates can be used with the same name but a differing organizational unit so that they can be distinguished (if the CA supports issuing certificates in this form). For example, you can see how Jetdirect populates the organizational unit: 86

  • 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
86
Effectively, the algorithm is going to be something like this:
If( dNSName is present)
{
Match dNS Name
}
Else
{
Match Common Name
}
For HTTPS, we saw that a mismatch caused a warning dialog box with Internet Explorer 6 and an
explicit Certificate Error with Internet Explorer 7. Combining everything we have learned so far, we
can form a very easy rule with SSL/TLS:
One name to one IP Address to one port number identifies one certificate.
For instance, looking at the previous trace:
w2003.example.internal => 192.168.0.1 + TCP 636 => LDAPS certificate
That was easy, right?
Well, things get more complicated due to a few factors:
•
Server Farms – having multiple servers respond to one name
•
Virtual Hosting – having one web site for many customers
•
Limited IP addresses – public servers require public IP addresses
•
SSL Certificates for the Internet cost money
Server farms are where I have several machines handling SSL requests in order to load balance.
For
example, if you do an nslookup on a major site, you may see more than one IP address.
Going back
to our LDAPS example, it would be something like this:
w2003.example.internal = 192.168.0.1, 192.168.0.2, 192.168.0.3
Each time the name w2003.example.internal is resolved to an IP address, a different IP address is
used.
This behavior allows for load balancing.
If each IP address is a separate machine, a single
certificate needs to be stored on multiple machines because of how the naming checks are done.
When distributing the same certificate to multiple machines, there is a danger around private key
protection.
Alternatively, separate certificates can be used with the same name but a differing
organizational unit so that they can be distinguished (if the CA supports issuing certificates in this
form).
For example, you can see how Jetdirect populates the organizational unit: