CreateSIS
- Wrapper for MakeSIS
,
SignSIS
and MakeKeys
syntax
CreateSIS
is a wrapper around around the PC tools
MakeSIS,
SignSIS and
MakeKeys to automate the
process of generating and signing SIS files. It supports creating new SIS files
from package files, signing existing package files and generating new
key/certificate pairs for purposes of signing.
If neither certificate or key are specified (as outlined in the
Usage Scenarios section below), a self-signed certificate will be generated
and used to sign the resulting SIS file. In addition, CreateSIS
may be used to dump details of signatures and certificate chains into a
pre-existing SIS file.
The following diagram shows how the PC based tool
(CreateSIS
) is used to construct an installation package (SIS
file) from component files, using instructions detailed in a PKG file, and sign
it.
From an MSDOS command-line prompt (or batch file) the syntax for
using CreateSIS
is as follows:
|
where
|
The user, having previously obtained a trusted EE certificate
(i.e. one that chains back to a trusted root in the target device SWI
certstore) and matching key, may either specify the signing key/certificate
pair on the CreateSIS
command line, using the -key
and -cert
parameters as specified above, or using the
package file syntax for specifying keys and certificates as defined in the
MakeSIS documentation. This
function uses the create
method, and requires a package file as
input. Optionally, the user may be required to specify a passphrase to decrypt
the private key using the -pass
parameter, this applies to both
keys.
Example:
createsis create -cert trustedchain.pem -key eecertkey.key mypackage.pkg
As above, the user may initially sign, or resign a pre-existing
SIS file using the sign
method. To sign a package, a key and
certificate chain must be provided on the command line. The output SIS file
will be different to the input SIS file, so the original data is not destroyed.
Example:
createsis sign -cert trustedchain.pem -key eecertkey.key mysis.sis mysis-signed.sis
A user may use the dump
method of CreateSIS to
display details of all valid signatures and the associated certificates in a
SIS file they provide.
Example:
createsis dump myssis.sis
In the event that no key/certificate pair is presented on the
command line, or in the package file, then the create
method will
generate a key and matching self-signed certificate, and use these to sign the
resulting SIS file.
In this situation, the DN in the certificate generated uses
strings from the MakeSIS
and locale settings from the host PC. The
DN will include the follow attributes:
Common Name -- derived English package name defined in the SIS header. If English is not available, we default to the first language specified. If the string length is less than 64 bytes, it shall be patched with random hexadecimal characters up to 64 bytes.
Vendor Name -- derived English package vendor's name defined in the SIS header. If English is not available, we default to the first vendor specified.
The generated certificate and key will be dumped into the
current working directory, in files called cert-gen.cer
and
key-gen.key
. If key-gen.key
exists, then the
certificate and key filenames will be indexed incrementally, i.e.
cert-genx.cer
and key-genx.key
, where
x is the incremental index.
Passphrase encryption is not an option. Users can provide it
with the -pass
option, or CreateSIS
will prompt for
the passphrase during key generation.
Also see the Notes section below.
If, when using the sign
method (as stated above) no
key/certificate pair are supplied either as command line parameters, or indeed
using the package file syntax, CreateSIS defaults to signing the specified SIS
file with an automatically generated self-signed certificate.
All the notes on user interaction and certificate generation from the Create and Self-sign a SIS file section apply to this case too.
Software Installation's (SWI’s) certificate handling has been modified such that, in the event of receiving a self-signed SIS file, it will validate the signatures chains without reference to the certificates contained in the SWI certstore. Pre-v9.1, self-signed certificate chains were rejected as invalid, as there would not have been a trust anchor present in the SWI certstore to act as root for the chain.
SWI’s OCSP check has been changed such that it can appropriately evaluate certificate chains terminating at an untrusted root. While it continues to be the case that SWI alerts the user to unknown certificates in trusted chains during an OCSP check, this is now considered the normal state of affairs for self-signed certificates and the user should not be alerted to the fact.