|
The process of adding a signed package or patch to your system involves
three basic steps:
Adding the certificates to your system's package keystore
with the pkgadm command
(Optional) Listing the certificates with the pkgadm command
Adding the package with the pkgadd command
or adding the patch with the patchadd command
For step-by-step instructions on adding signed packages to your system,
see Adding and Removing Signed Packages (Task Map). For step-by-step instructions on adding
signed patches to your system, see Adding Signed Patches With patchadd Command (Task
Map).
Using Sun's Certificates to Verify Signed Packages and Patches
A stream-formatted
SVR4-signed package or patch contains an embedded PEM-encoded PKCS7
signature. This signature contains at a minimum the encrypted digest of the
package or patch, along with the signer's X.509 public key certificate. The
package or patch can also contain a certificate chain
that is used to form a chain of trust from the signer's certificate to a locally
stored trusted certificate.
The PEM-encoded PKCS7 signature is used to verify the following:
The package came from the entity that signed it.
The entity indeed signed it.
The package hasn't been modified since the entity signed it.
The entity that signed it is a trusted entity.
The following table describes the encryption terminology associated
with signed packages and patches.
Term | Definition | |
|---|
ASN.1 | Abstract Syntax Notation 1 (ASN.1) is a way to express a set of abstract objects.
For example, ASN.1 defines a public key certificate, all of the objects that
make up the certificate, and the order in which the objects are collected.
However, ASN.1 does not specify how the objects are serialized for storage
or transmission. | |
base64 | base64 is a method of encoding arbitrary binary data as ASCII text. | |
DER | Distinguished Encoding Rules (DER) is a binary representation of an ASN.1
object. DER defines how an ASN.1 object is serialized for storage or transmission
in computing environments. | |
PEM | The Privacy Enhanced Message
(PEM) is a way to encode a file (in DER or other binary format) using base64
encoding and some optional headers. Initially used for encoding MIME-type
email messages. PEM is also used extensively for encoding certificates and
private keys into a file that exists on a file system or in an email message. | |
PKCS7 | The Public Key Cryptography
Standard #7 (PKCS7) describes a general syntax for data that may have cryptography
applied to it, such as digital signatures and digital envelopes. | |
X.509 | The International Telecommunication Union-Telcom (ITU-T) recommendation X.509
specifies the widely adopted X.509 public key certificate syntax. This recommendation defines a framework for the provision of authentication
services. X.509 describes two levels of authentication: Simple authentication - using a password as a verification
of claimed identity. Strong authentication - involving credentials formed
using cryptographic techniques. While simple authentication offers some limited
protection against unauthorized access, use only strong authentication as
the basis for providing secure services.
| |
Digital certificates, issued and authenticated by Sun Microsystems,
are used to verify that the downloaded package or patch with the digital signature
has not been compromised. These certificates are imported into your system's
keystore.
All Sun certificates are issued by Baltimore Technologies, which recently
bought GTE CyberTrust.
Access to a keystore is protected by a special password that you specify
when you import the Sun certificates into your system's keystore.
If you use the pkgadm listcert command, you can view
information about your locally stored certificates in the package keystore.
For example:
# pkgadm listcert -P pass:store-pass
Keystore Alias: GTE CyberTrust Root
Common Name: GTE CyberTrust Root
Certificate Type: Trusted Certificate
Issuer Common Name: GTE CyberTrust Root
Validity Dates: <Feb 23 23:01:00 1996 GMT> - <Feb 23 23:59:00 2006 GMT>
MD5 Fingerprint: C4:D7:F0:B2:A3:C5:7D:61:67:F0:04:CD:43:D3:BA:58
SHA1 Fingerprint: 90:DE:DE:9E:4C:4E:9F:6F:D8:86:17:57:9D:D3:91:BC:65:A6...
|
The following table describes the output of the pkgadm listcert command.
Field | Description |
|---|
Keystore Alias | When you retrieve
certificates for printing, signing, or removing, this name must be used to
reference the certificate. |
Common Name | The common name of
the certificate. For trusted certificates, this name is the same as the keystore
alias. |
Certificate Type | Can be one of
two types: Trusted Certificate - A certificate that can be used as a
trust anchor when verifying other certificates. No private key is associated
with a trusted certificate. Signing Certificate - A certificate that can be used when
signing a package or patch. A private key is associated with a signing certificate.
|
Issuer Common Name | The name of the entity that issued, and therefore
signed, this certificate. For trusted certificate authority (CA) certificates,
the issuer common name and common name are the same. |
Validity Dates | A date range that
identifies when the certificate is valid. |
MD5 Fingerprint | An MD5 digest of the certificate. This digest can
be used to verify that the certificate has not been altered during transmission
from the source of the certificate. |
SHA1 Fingerprint | Similar to an MD5 Fingerprint, except that it is
calculated using a different algorithm. |
Each certificate is authenticated by comparing its MD5 and SHA1 hashes,
also called fingerprints, against the known correct fingerprints
published by the issuer.
SunSolve Online's Trusted Certificates
SunSolve Online uses the following certificates to verify the
digital signatures on signed patches with the previous Solaris patch management
tools (smpatch command), including PatchPro:
Top-level certificate, called the Root Certificate Authority
(CA)
A subordinate CA, which is the Sun Microsystems Inc., CA Class
B certificate.
An additional certificate issued by Sun Enterprise™ Services, called the patch management certificate
A certificate authority certifies the relationship
between public keys that are used to decrypt the digital signature with the
patch and the owner of the public keys.
The Sun Root CA, Sun Class B CA, and the patch signing certificate are
included with the Solaris patch management tools, including PatchPro. These
three certificates provide a certificate chain of trust in the patch verification
process whereby the Sun Root CA trusts the Class B CA, and the Class B CA
trusts the patch management certificate. And, ultimately, the GTE CyberTrust
CA trusts the Sun Root CA.
Importing Sun's Trusted Certificates
You
can obtain Sun's trusted certificates for adding signed packages and patches
in the following ways:
Java keystore - Import
Sun's Root CA certificate that is included by default in the Java keystore
when you install the Solaris release.
Sun's Public Key Infrastructure (PKI)
site - If you do not have a Java keystore available on your
system, you can import the certificates from this site.
https://ra.sun.com:11005/
PatchPro's keystore -
If you have installed PatchPro for adding signed patches with the smpatch command, you can import Sun's Root CA certificate from the
Java keystore.
|
Previous