Company logo
SearchMapHome
 
Certificate Types and Their Certificate Stores after Import
Certificate
A certificate is an electronic ID that can be held by an application. The ID includes information that identifies the holder, the issuer, and a unique key that is used to create and verify digital signatures. The syntax of these certificates conforms to the X.509 specification, and these certificates are also known as X.509 Certificates. The certificates also have an associated private key.
Self-signed Certificate
A self-signed certificate is a certificate with no certificate authority. These certificates can be created by anyone.
 
NOTICE
Validity of Self-Signed Cerificates
Self-signed certificates allow local deployments without the overhead of obtaining commercial certificates. When using self-signed certificates, the owner of the Desigo CC system is responsible for maintaining their validity status, and for manually adding them to and removing them from the list of trusted certificates.

Self-signed certificates must only be used in accordance with local IT regulations (several CIO organizations do not allow them, and network scans will identify them). Importing the commercial certificates follows the same procedures.

You must ensure the compliant installation of the trusted material on the involved machines, for example, on all Installed Clients. In some organizations, this must be done by the IT organization.
 
Root Certificate
A root certificate is an unsigned public key certificate, or a self-signed certificate, and is part of a public key infrastructure scheme. The most common commercial variety is based on the ISO X.509 standard. Normally an X.509 certificate includes a digital signature from a certificate authority (CA) which vouches for correctness of the data contained in a certificate.
Host Certificate
A host certificate is a certificate that is used to identify machines by hostname for ensuring security. A host credential consists of an X.509 certificate and a private key.
Private Key
A private key is a secret number known only to the holder of a certificate. This number allows the holder to create digital signatures and decrypt data. If the secret number is revealed to unauthorized parties, the associated certificate can no longer be trusted or used.
Wildcard Certificate
A wildcard certificate is a certificate containing the wildcard asterisk (*). They are used to cover complete sub-domains or to cover all services you offer on your domain. The subject starts with an asterisk (*), it covers one level till the first dot (that is, it does not span over a dot).
Examples: *.dom01.company.net (would cover all machines in the dom01.company.net intranet) or *.company.com (would cover all logical services offered on the company.com domain, for example, e-mail.company.com for a mail service, and www.company.com for the website).
Microsoft only supports wildcards for the first section of the DNS name, that is, dom01.*.net is not valid.
Multi-host Certificates
Multihost certificates are used, for example, when a host is reachable by different host names. So a host might serve the address DesigoCC.myDomain.com to the internet, while it is reachable as hostX.my.intranet or via its fix IP 123.4.5.6 from the intranet. Alternative host names or IP addresses are stored in the Subject Alternative Name property (this is a certificate V3 extension) or when you want to cover a couple of dedicated machines with one certificate.
Tips for Working with Multi-host Certificates
You can create a host certificate having the Subject name field as a unique name (for example, *.in002.company.net) and not necessarily the full computer name. However, the Subject Alternative Name property must contain all the desired host names of the machines by which the machine can be accessed. This property allows you to specify a list of host names to be protected by a single certificate.
For example, if the machine's host names and IP addresses are
DNS.1 = foobaa.dom01.company.net
DNS.2 = ABCXY022PC.dom01.company.net
DNS.3 = ABCXY022PC.dom01.company.net
IP.1 = XXX.12.34.567
IP.2 = XXX.12.34.5
The Subject Alternative Name property must contain all these names.
You can use such a certificate for securing a website/Web application, Web communication over CCom port, and for securing Client/Server communication. In this case, you can provide any of the Subject Alternative Names in the Host name field. Note that the Certificate issued to field should contain this multihost certificate with the host name as one of the Subject Alternative Names.
Certificate Authority (CA)
A Certificate Authority (CA) is an administrator or organization that is responsible for creating certificates. The Certificate Authority must verify that the information in the certificate is correct and add a digital signature to the certificate that is used to verify that the information is unchanged. Each CA must have its own certificate which is used to create the digital signatures.
Certificate Store
A certificate store is a place where certificates and private keys can be stored on the file system. All Windows systems provide a registry-based store called Windows Certificate store. All the systems support a directory containing the certificates stored in a file which is also called an OpenSSL Certificate store.
Each of the system certificate stores has the following types:
Local machine certificate store
This type of certificate store is local to the computer and is global to all users on the computer.
This certificate store is located in the registry under the HKEY_LOCAL_MACHINE root.
Current user certificate store
This type of certificate store is local to a user account on the computer.
This certificate store is located in the registry under the HKEY_CURRENT_USER root.
All current user certificate stores inherit the contents of the local machine certificate stores. For example, if a certificate is added to the local machine Trusted Root Certification Authorities certificate store, all current user Trusted Root Certification Authorities certificate stores also contain the certificate.
The following table displays certificate types, and the file formats supported for importing them in the Windows Certificate store location.
Certificate Type
Format (file extension)
Windows Certificate Store Location after Import
Remarks
Root
.cer
Local machine certificates > Trusted Root Certification Authorities
and
User certificates > Trusted Root Certification Authorities
.cer format is used only for storing the Certificate and not the Private Key.
.pfx, , along with a private key
X
Not for distribution.
Used for creating a child host certificate.
Host
.cer
X
Not for distribution.
.pfx , along with a private key
Local machine certificates > Personal
You must provide permissions on private keys of the Host certificate to the user on the Client/FEP machine who wants to run the Desigo CC Client.

On a Client/FEP, the logged-on user should have Read rights on the host certificate.

Even if a Client/FEP system user is included in the Administrators group and the Administrator group has rights on the private key of the host certificate, you still need to explicitly assign rights to the user of the host certificate’s private key.
Self-signed
.cer
X
Not for distribution.
.pfx , along with private key
Local machine certificates > Trusted Root Certification Authorities and Personal