HP MFP Digital Sending Software (DSS) 5.0 - Security Features

8
When using a remote Configuration Utility the settings will appear twice, once for the CU server and
once for the DSS server.
IMPORTANT NOTE: At this time DSS is unable to function if only TLS 1.1 and /or TLS 1.2 are enabled and
SSL 3.0 and TLS 1.0 are disabled. If the server is configured for only TLS 1.1 and/or 1.2 then the DSS
service will fail to start. If this occurs, it can be remedied by once again enabled SSL 3.0 and / or TLS 1.0.
Server Certificate Validation
When an SSL / TLS client receives the server’s certificate with the server’s public key in it, the client has a
decision to make. Should the client just trust that the certificate is OK or should it test to see that it can
be trusted by validating the certificate?
Certificate Authority certificates are used for certificate validation. Each certificate is signed by the CA
that created it. If an entity trusts that any certificates it might get that are signed by a particular CA, let’s
call it CA1, are good then the client should put the certificate for CA 1 in its trusted root certification
authority’s store. The flow would go something like this:
1. Entity 1, which will be the client in the SSL / TLS communication, trusts that any certificates it
gets that are signed by CA1 are trustworthy.
2. Entity 1 obtains the certificate from CA1 and puts it into its own Trusted Root Certification
Authorities store.
3. Entity 1 initiates an SSL / TLS session with entity 2, so Entity 1 is the client and Entity 2 is the
server.
4. Entity 2 passes its public key certificate to entity 1, this certificate is signed by the CA named
CA1.
5. Entity 1 gets entity 2’s certificate and sees that it has been signed by CA1. Entity 1 does some
checks to see if it can trust the certificate it received:
a. A check to see if CA1’s certificate is in its Trusted Root Certification Authorities store,
which it is because it was put there in step 2 above.