The pkgsign tool does not perform all possible checks for its inputs when signing packages. Therefore, it is important to check signed packages to ensure that they can be properly installed after being signed.
This section shows errors that can occur when attempting to install or update a signed package and provides explanations of the errors and solutions to the problems.
A signed package can fail to install or update for reasons that are unique to signed packages. For example, if the signature of a package fails to verify, or if the chain of trust cannot be verified or anchored to a trusted certificate, the package fails to install.
The image and publisher properties described in this section influence the checks that are performed on signed packages.
To configure image properties, use the set-property, add-property-value, remove-property-value, and unset-property subcommands of the pkg command.
To specify signature policy and required names for a particular publisher, use the --set-property, --add-property-value, --remove-property-value, and --unset-property options of the set-publisher subcommand.
See Configuring Package Signature Properties in Updating Systems and Adding Software in Oracle Solaris 11.4 for examples.
Configure the following image properties to use signed packages:
The value of this property determines the checks that will be performed on manifests when installing, updating, modifying, or verifying packages in the image. The final policy applied to a package depends on the combination of image policy and publisher policy. The combination will be at least as strict as the stricter of the two policies taken individually. By default, the package client does not check whether certificates have been revoked. To enable those checks, which might require the client to contact external web sites, set the check-certificate-revocation image property to true. The following values are allowed:
Ignore signatures for all manifests.
Verify that all manifests with signatures are validly signed but do not require all installed packages to be signed.
This is the default value.
Require that all newly installed packages have at least one valid signature. The pkg fix and pkg verify commands also warn if an installed package does not have a valid signature.
Follow the same requirements as require-signatures but also require that the strings listed in the signature-required-names image property appear as a common name of the certificates used to verify the chains of trust of the signatures.
The value of this property is a list of names that must be seen as common names of certificates while validating the signatures of a package.
The relative path name (relative to the root of the image) of the directory that contains the trust anchors for the image. The default is etc/certs/CA.
If you create your own SSL Certificate Authority certificates, put those certificates in the directory named by trust-anchor-directory and refresh the ca-certificates service as described in How to Use a Custom Certificate Authority Certificate. Put the CA certificates directly in the directory named by trust-anchor-directory; do not put the certificates in another subdirectory.
Configure the following publisher properties to use signed packages from a particular publisher:
The function of this property is identical to the function of the signature-policy image property except that this property applies only to packages from the specified publisher.
The function of this property is identical to the function of the signature-required-names image property except that this property applies only to packages from the specified publisher.
The following error occurs when a certificate in the chain of trust is missing or otherwise erroneous.
pkg install: The certificate which issued this certificate: /C=US/ST=California/L=Menlo Park/O=pkg5/CN=cs1_ch1_ta3/emailAddress=cs1_ch1_ta3 could not be found. The issuer is: /C=US/ST=California/L=Menlo Park/O=pkg5/CN=ch1_ta3/emailAddress=ch1_ta3 The package involved is: pkg://test/example_pkg@1.0,5.11-0:20110919T184152Z
In this example, there were three certificates in the chain of trust when the package was signed. The chain of trust was rooted in the trust anchor, a certificate named ta3. The ta3 certificate signed a chain certificate named ch1_ta3, and ch1_ta3 signed a code signing certificate named cs1_ch1_ta3.
When the pkg command tried to install the package, it was able to locate the code signing certificate, cs1_ch1_ta3, but could not locate the chain certificate, ch1_ta3, so the chain of trust could not be established.
The most common cause of this problem is failing to provide the correct certificates to the -i option of pkgsign.
The following error is similar to the error shown in the previous example but the cause is different.
pkg install: The certificate which issued this certificate: /C=US/ST=California/L=Menlo Park/O=pkg5/CN=cs1_cs8_ch1_ta3/emailAddress=cs1_cs8_ch1_ta3 could not be found. The issuer is: /C=US/ST=California/L=Menlo Park/O=pkg5/CN=cs8_ch1_ta3/emailAddress=cs8_ch1_ta3 The package involved is: pkg://test/example_pkg@1.0,5.11-0:20110919T201101Z
In this case, the package was signed using the cs1_cs8_ch1_ta3 certificate, which was signed by the cs8_ch1_ta3 certificate.
The problem is that the cs8_ch1_ta3 certificate was not authorized to sign other certificates. Specifically, the cs8_ch1_ta3 certificate had the basicConstraints extension set to CA:false and marked critical.
When the pkg command verifies the chain of trust, it does not find a certificate that is allowed to sign the cs1_cs8_ch1_ta3 certificate. Since the chain of trust cannot be verified from the leaf to the root, the pkg command prevents the package from being installed.
The following error occurs when a chain of trust ends in a self-signed certificate that is not trusted by the system.
pkg install: Chain was rooted in an untrusted self-signed certificate. The package involved is:pkg://test/example_pkg@1.0,5.11-0:20110919T185335Z
When you create a chain of certificates using OpenSSL for testing, the root certificate is usually self-signed, since there is little reason to have an outside company verify a certificate that is only used for testing.
In a test situation, there are two solutions:
The first solution is to add the self-signed certificate that is the root of the chain of trust into /etc/certs/CA and refresh the system/ca-certificates service. This mirrors the likely situation customers will encounter where a production package is signed with a certificate that is ultimately rooted in a certificate that is delivered with the operating system as a trust anchor.
The second solution is to approve the self-signed certificate for the publisher that offers the package for testing by using the --approve-ca-cert option with the pkg set-publisher command.
The following error occurs when the value on the signature action could not be verified using the certificate that the action claims was paired with the key used to sign the package.
pkg install: A signature in pkg://test/example_pkg@1.0,5.11-0:20110919T195801Z could not be verified for this reason: The signature value did not match the expected value. Res: 0 The signature's hash is 0ce15c572961b7a0413b8390c90b7cac18ee9010
There are two possible causes for an error like this:
The first possible cause is that the package has been changed since it was signed. This is unlikely but is possible if the package manifest has been hand edited since signing. Without manual intervention, the package should not have changed since it was signed because pkgsend strips existing signature actions during publication because the old signature is invalid when the package gets a new time stamp.
The second, more likely cause is that the key and certificate used to the sign the package were not a matched pair. If the certificate given to the -c option of pkgsign was not created with the key given to the -k option of pkgsign, the package is signed, but its signature will not be verified.
The following error occurs when a certificate in the chain of trust uses a critical extension that pkg does not understand.
pkg install: The certificate whose subject is /C=US/ST=California/L=Menlo Park/O=pkg5/CN=cs2_ch1_ta3/emailAddress=cs2_ch1_ta3 could not be verified because it uses a critical extension that pkg5 cannot handle yet. Extension name:issuerAltName Extension value:<EMPTY>
Until pkg learns how to process that critical extension, the only solution is to regenerate the certificate without the problematic critical extension.
The following error is similar to the previous error except that the problem is not with an unfamiliar critical extension but with a value that pkg does not understand for an extension that pkg does understand.
pkg install: The certificate whose subject is /C=US/ST=California/L=Menlo Park/O=pkg5/CN=cs5_ch1_ta3/emailAddress=cs5_ch1_ta3 could not be verified because it has an extension with a value that pkg(7) does not understand. Extension name:keyUsage Extension value:Encipher Only
In this case, pkg understands the keyUsage extension, but does not understand the value Encipher Only. The error looks the same whether the extension in question is critical or not.
The solution, until pkg learns about the value in question, is to remove the value from the extension, or remove the extension entirely.
The following error occurs when a certificate has been used for a purpose for which it was not authorized.
pkg install: The certificate whose subject is /C=US/ST=California/L=Menlo Park/O=pkg5/CN=ch1_ta3/emailAddress=ch1_ta3 could not be verified because it has been used inappropriately. The way it is used means that the value for extension keyUsage must include 'DIGITAL SIGNATURE' but the value was 'Certificate Sign, CRL Sign'.
In this case, the certificate ch1_ta3 has been used to sign the package. The keyUsage extension of the certificate means that the certificate is only valid to sign other certificates and CRLs (Certificate Revocation Lists).
The following error indicates that the certificate has been changed since it was last retrieved from the publisher.
pkg install: Certificate /tmp/ips.test.7149/0/image0/var/pkg/publisher/test/certs/0ce15c572961b7a0413b8390c90b7cac18ee9010 has been modified on disk. Its hash value is not what was expected.
The certificate at the provided path is used to verify the package being installed, but the hash of the contents on disk do not match what the signature action thought they should be.
The simple solution is to remove the certificate and allow pkg to download the certificate again.
The following error indicates the certificate in question, which was in the chain of trust for the package to be installed, was revoked by the issuer of the certificate.
pkg install: This certificate was revoked: /C=US/ST=California/L=Menlo Park/O=pkg5/CN=cs1_ch1_ta4/emailAddress=cs1_ch1_ta4 for this reason: None The package involved is: pkg://test/example_pkg@1.0,5.11-0:20110919T205539Z