Appendix C. Digital Certificates
A digital certificate is an electronic document which conforms to the
International Telecommunications Union’s X.509 specification. It
is a document which typically contains the owner’s name and public
key, the expiration date of the public key, the serial number of the certificate,
and the name and digital signature of the organization which issued the
certificate. The digital certificate binds together the owner’s
name and a pair of electronic keys (a public key and a private key) that
can be used to encrypt and sign documents.
Encrypting and digitally signing documents using certificates provides
the following assurances about document transmissions:
Only the addressee
(and no unauthorized users) can read the message. Encryption provides
this assurance.
The message cannot
be tampered with. That is, data cannot be changed, added, or deleted without
the sender’s knowledge. A document’s digital signature provides
this assurance.
Parties sending
documents are genuinely who they claim to be. Likewise, when those parties
receive documents signed by the sender, they can be confident about the
source of the documents. A document’s digital signature provides
this assurance.
The parties who
send documents cannot readily claim they did not send them. This is referred
to as non-repudiation of origin. A document’s digital signature
provides this assurance.
Parties who are
sent documents cannot readily claim they did not receive them. This is
referred to as non-repudiation of receipt. The signed document acknowledgment
provides this assurance.
Using the certification
The public key in the FDA’s certificate is used to encrypt a document
for transmission. The FDA ESG uses the public key to verify the digital
signature of a document received from a specified source.
Before encrypted and signed documents (sent submissions) are exchanged
with the FDA ESG, there must be a certificate exchange to obtain the other’s
certificate and public key. Each party obtains a certificate with a public-private
key pair, either by generating a self-signed certificate or by obtaining
a certificate from a Certificate Authority. The private half of the key
pair always remains on the party’s computer. The public half is
provided to the FDA ESG during the registration process and includes the
certificate and public key, or the certificate alone.
Certificates not accepted by the registration module
There are situations when a valid certificate is not accepted by the
registration module and is identified as invalid. If this occurs, zip
the certificate file and email it to the FDA ESG administrator at esgreg@hhs.fda.gov.
Once received, FDA will assess the certificate and send a response.
Certificates not accepted by the FDA ESG
The FDA ESG cannot accept certificates with blank data elements in the
Issuer or Subject fields. These certificates will cause the FDA
ESG to fail due to a defect in the Gateway software. The certificates
provided should be valid for at least one year and no more than two years.
Note, this requirement applies to both Pre-production (Test) and Production
ESG systems.
DO NOT SUBMIT CERTIFICATES WITH BLANK DATA FIELDS
IN THE ISSUER AND SUBJECT FIELDS
Where to obtain a certificate
The FDA ESG supports Public Key Infrastructure (PKI) to securely trade
submissions over the Internet. PKI is a system of components that use
digital certificates and public key cryptography to secure transactions
and communications.
PKI uses certificates issued by certificate authorities (CAs) to provide
authentication, confidentiality, integrity and non-repudiation of data.
Options
There are two PKI options supported&endash;commercial in-house, and
outsourced PKIs. The option chosen can depend on a number of factors,
such as cost, human and system resources, and the degree or sophistication
of security desired. PKI establishes digital identities that can be trusted.
The CA is the party in a PKI that is responsible for certifying identities.
In addition to generating a certificate, this entails verifying the identity
of a subscriber according to established policies and procedures. This
is the case for in-house and outsourced PKIs.
In an organization that generates and uses its own self-signed certificates,
the trading parties must verify the certificates and establish a direct
trust. Once established that an identity or issuer of an identity can
be trusted, the trust anchor’s certificate is stored in a local
trust list. The FDA ESG has a local trust list for storing and managing
established trust relationships. The application maintains a list of common
public CA certificates similar to those kept in web browsers. Although
convenient, this predetermination of trust might not complement every
organization’s security policy. The decision of who to trust rests
with the individual organization.
In-House
An in-house PKI makes it possible to achieve complete control of security
policies and procedures. It also carries the burden of management and
cost to set up and maintain the system.
Outsourced
Third-party certificate authorities can be leveraged to purchase keys
and X.509 certificates for general use in trading and let the CA manage
security policies and details such as certificate revocation. The level
of outsourcing can range from purchasing an end-entity public key certificate
of a certain validity period from a commercial PKI to outsourcing all
of the PKI services that the organization requires.
If you are trying to use an outsourced certificate, the following are
the companies that sell the X.509 certificates (Displayed in alphabetical
order). Click on the link to go to website where you can purchase the
certificate.
After you make the choice from the above list follow the on screen instructions
to complete the purchase.
CA will send you an email with PIN number and a link to a website where
you can import/install the certificate. Accept all defaults and say ”yes”
to all pop-ups, your certificate will be installed in your browser. Note,
if you are using WebTrader, you do not have to install the certificate
on the same machine that you will be using. Once the certificate is installed
in the browser you can export the public and private keys out and use
them where ever you want. AS1/AS2 users will need to install the certificates
in their system. Configuring the certificates may defer from sponsor to
sponsor depending on what gateway software being used.
From Internet Explorer go to Tools àInternet
Options à Content
tab àCertificates
Select your certificate in the Personal tab.
Click on the Export button to create public and
private keys, which can be used for the Gateway.
To export public key (.cer or .p7b) select Next
on the next screen
Select ¤
No, do not export the private key option and click on the Next
button.
Select the options as shown on the screen below. Click
on the Next button. Or if you want to export the certificate with
.P7B extension/format or to export .CER extension/format follow the next
step.
Select ¤
Cryptographic Message syntax Standard &endash; PKCS #7 Certificates (.P7B),
check R
Include all certificate in the certification path if possible.
Select ¤DER
encoded binary X.509 (.CER) and click on the Next button.
Give a file name and select the location where you want
to save the file. Click on the Next button. Then
click on Finish.
You public key is ready. This is the key that you should use when registering.
To export private key (.PFX or .P12)
Select the certificate and click on Export, Click
on net on the next screen
Select ¤
Yes, export the private key and click on the Next button.
Select the options as shown below and click on the Next
button.
Create a password for your private key. Confirm the
password and click on the Next button. If you
forget the password you can export the private key again and create a
password.
Create a file name and select the location where you
want to save the file and click on the Next button. On the next
screen, click on Finish and then click on OK.
