The Virginia Tech Certification Authority is a service at Virginia Tech that is responsible for issuing and managing digital certificates and public keys for Virginia Tech affiliated entities. The VTCA is the core of the Virginia Tech Public Key Infrastructure (PKI). The VTCA guarantees the identity and the authenticity of the entities it issues digital certificates to by using approved policies and procedures outlined in the Virginia Tech Certification Policy (CP)document.
If you need help installing VTCA certificates please contact 4help at:
PKI or Public Key Infrastructure is a set of comprehensive system policies, procedures, and technologies working together to allow secure and confidential communication between internet users. PKI is based on the idea of encryption using public and private keys.
PKI uses key pairs (public and private keys)where the public key is digitally signed by a third party known as a certification authority.
The relationship between PKI and security lies in the fact that the public and private keys can be used for encryption. To secure online transactions one must hide the content of the data being transmitted over the wire, PKI is used to do this task through the use of SSL and TLS.
The major components of PKI are listed below.
A Certification Authority is a trusted third party that verifies the identity of an entity registering for a digital certificate. Once a Certification Authority authenticates the requesting entity's identity, it issues a digital certificate to the requesting entity binding his or her identity to a public key. (Digital certificates can be issued to organizations and devices in addition to people)
Digital Certificate is an electronic document that binds a public key to an entity such as an organization, machine, or a person. The binding of the identity and the public key is done by the issuing CA. The issuing CA will assume the responsibility of verifying the identity of the requesting party. The requesting party is the entity requesting the binding of its public key to its identity.
Yes all digital certificates have an explicit start date and an explicit expiration date. Most applications check the validity period of a certificate when the digital certificate is used.
PKI provides the critical element of "trust" in electronic transactions as well as communications. It provides a means for relying parties to know that another individual's or entity's public key actually belongs to that individual/entity. Certification Authority organizations have been established to address this need.
The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, full-featured, and Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library. The project is managed by a worldwide community of volunteers that use the Internet to communicate, plan, and develop the OpenSSL toolkit and its related documentation.
Certificates are kept in special repositories called keystores and can be distributed in several different formats:
1. X509 format (.cer and .crt file-extension for Windows) certificate is widely supported. This file represents the individual certificate.
2. Cryptographic Message Syntax -PKCS #7 Format (.p7b file extension for Windows) This format is used for exporting complete chain.
3. Personal Information Exchange syntax -PKCS #12 Format (.pfx and .p12 file extensions for Windows). This format is used for exporting the public/private key pair. Very helpful in importing key pairs to the browsers.
4. Certificate Signing Request (CSR) Syntax -PKCS #10 Format. This format is used for generating signing requests to trusted certificate signing authorities.
$openssl x509 -in cert.pem -noout -text
$openssl x509 -in cert.pem - inform PEM -out cert.der -outform DER
You can start by editing the file, If the file starts with "------begin ------" and the file contains data that looks like this:
M+WetKOXAYamLPgkm6ubt3/90JPVh8BPR92d+a9yY54j+wi2VaX768KKzXfQp+MSG
Yna1NtDWloAkzDuIbkaPDw6CMl0lD5jRsHDNRh5qvhU+G6okGrQIV8291E3rbDVM
mEvchRSK8TUBH0o39ZFtnrdzqs02jsE/ke9Dc78w67W3ffCIFWMr50sKpRr9nyiB
XSkEuSWmvvo2vMX4yvlBWAeMTSTEKDOWkiJ6g4M9oE57C7Rp2l0A+XC1I29E4mjr
KBv3G9LFe18fgU77+PYH85qAbDgTCknc5JhofacbkSFsvPn4p41nmvoKbtIKBBxH
UVMFfq342wkq9Yo/g+4tIWsrA23om5xVhXmMtnS+ACl0YUDcotkYJMnb+dr MWO+am
of/NAKjpDCm37UpJrGd6LdQGeN7+l0HNpkVQ0JYcJCShpO2y5+hNCGY5CJQm7g
LNLzdpLqryuMHG3IOWxiTc/BFv73hr5aGTkM2IQcDqh5YBzeVuycgRBM3yVG05Vk
T2x65/bkffSGs0MOb19vhLscxZjVMuo4R+mMCkTuiEx0a63o202HpQvHIkXuvms2
L9W9yqMrVOzA3aZ5N/diA7ziNXbYL3EZauWCVrigdkmE7XMxO+2Y/OGXDnif895==
"-----end ------"
then it is a PEM format. If the file looks like a binary file where there is nothing understandable, then it is DER
The VT Global Qualified Web Server CA hosts the following test web pages that allow you to test your software with certificates that are (i) valid, (ii) revoked, and (iii) expired.
(i) valid - https://sieswin08.cc.vt.edu:443
(ii) revoked - https://sieswin08.cc.vt.edu:8443
(iii) expired - https://sieswin08.cc.vt.edu:8080
A certificate signing request (CSR) is one of the first steps towards getting your own SSL/TLS certificate. The CSR contains information (e.g. common name, organization, country) the Certificate Authority (CA) will use to create your certificate. It also contains the public key that will be included in your certificate and is signed with the corresponding private key. At VT we only need the Common Name (CN) to be included on the CSR. Defaults can be used on all the other fields.
Common name has the fully qualified domain name (FQDN) of your server.
For ex:
*.example.com
www.example.com
mail.example.com
The Subject Alternative Name (SAN), also known as SubjectAltName or SAN extension, is an extension to the X.509 specification for digital certificates used in Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols. The SAN field allows a single SSL certificate to specify multiple host names for a single entity (e.g., a web server).
Yes, however, you may want to backup or export your current certificate before removing it. Your certificate must have at least a 2048 key.
Follow the directions at https://support.globalsign.com/customer/portal/articles/1227403-generate-csr-or-renew-certificate---internet-information-services-iis-7.
For RSA private key:
You must specify your key size to be at least 2048 bits. This command will prompt you to enter a pass phrase to encrypt the private key.
$openssl genrsa -aes256 -out private.key 2048
For EC private key:
You must specify your key size to be at least 256 bits. This command will prompt you to enter a pass phrase to encrypt the private key.
$openssl ecparam -name prime256v1 -genkey |openssl ec -aes256 -out private.key
For Certificate signing request (CSR) using the above private key:
$openssl req -new -key private.key -out server.csr -subj "/DC=edu/DC=vt/CN=YOUR CN HERE"
Important: Be sure to keep all of the files created in the above procedure and any passwords used in a safe place.
You will receive your certificate from IMCS in DER format. You must convert it to PEM format.
$openssl x509 -inform DER -in download.cer -outform PEM -out download.pem
Then you can package your certificate to a PKCS #12 file using the below OpenSSL command:
openssl pkcs12 -export -inkey key.pem -in download.pem -out myserver.p12 -name "my test cert"
Where:
download.cer is: The certificate you received from IMCS
key.pem: The key you created when you made your CSR request
myserver.p12:is the output file where the PKCS #12 file will be stored
my test cert: just a friendly name that can be anything you like
Reference http://www.openldap.org/ for the latest information on configuring TLS/SSL for OpenLDAP servers.
Reference: https://support.globalsign.com/#category_SSL_Installation for the latest information on configuring Apache and Tomcat servers