Generate a Self-Signed Certificate for Signing on iOS

You can use a self-signed certificate for testing purposes, but you’ll need to ensure the certificate is trusted by all the devices a PDF is opened on (including PCs and Macs with Acrobat). A self-signed certificate will probably also generate warnings about its keyUsage extension (the self-signed certificate must permit certificate signing — keyCertSign, see RFC 5280).

Creating a self-signed certificate authority (CA) allows for more flexibility: Trusting it eliminates warnings for all certificates signed by that CA. This can be used for signature validation testing after adding the CA certificate and configuring it as trusted. This approach may also be applicable to closed infrastructures where it’s acceptable to manage trust internally.

Warning

In production, always use a certificate from a valid certificate authority. Make sure the certificate’s keyUsage has the digitalSignature permission set (see RFC 5280).

Self-Signed Certificate

The simplest way to test document signing is through a self-signed RSA certificate using OpenSSL or LibreSSL. To do this, use the following OpenSSL command:

openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem

ECDSA certificates can be created using the openssl ecparam command.

Self-Signed Certification Authority and Signing a Certificate

More advanced configuration consists of creating a self-signed certificate authority and using it as a root certificate to create a signing certificate. In a system that trusts such a CA certificate, it isn’t different from a certificate issued by a globally known root authority.

OpenSSL in macOS

Default OpenSSL configuration in macOS doesn’t set relevant options for certification authority generation. One of the ways to solve this is by updating the system configuration.

To do this, add the following lines to /etc/ssl/openssl.cnf. For more information, refer to the community recommendations:

[ v3_ca ]
basicConstraints = critical,CA:TRUE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always

Creating a Certification Authority

Generate a private key file named test-ca.key:

openssl genrsa -out test-ca.key 2048

Create and sign a certificate file named test-ca.cert for a CA with the common name (CN) My Test CA v1:

openssl req \
  -x509 -new -nodes -key test-ca.key \
  -subj "/CN=My Test CA v1" \
  -days 3650 -reqexts v3_req -extensions v3_ca \
  -out test-ca.cert

Creating a Signing Certificate

Generate a private key file named test-signer.key and a certificate signing request file named test-signer.csr with the CN My Testing Document Signer:

openssl req \
  -utf8 -nameopt oneline,utf8 -new -newkey rsa:2048 -nodes \
  -subj "/CN=My Testing Document Signer" \
  -keyout test-signer.key -out test-signer.csr

Create a signing certificate file from the request and name it test-signer.cert:

openssl x509 \
  -days 365 \
  -CA test-ca.cert -CAkey test-ca.key -CAcreateserial \
  -in test-signer.csr -req \
  -out test-signer.cert

Outcome

The process provides four important files:

  • test-ca.cert — A self-signed CA certificate (also the only component of the CA chain). This is what has to be trusted to accept child certificates.

  • test-ca.key — A self-signed CA private key that’s necessary to sign more certificates by the same CA.

  • test-signer.cert and test-signer.key — A signer certificate and a private key used for signing in the signing service — for example, our signing service reference implementation.