SSL-Certificates

From TLDinfo
Jump to: navigation, search

Contents

Introduction

How it works

SSL (Secure Sockets Layer) certificates guarantee the authenticity of a website identity through a specific validation process executed by a certification authority.
The certified SSL encryption ensures that information is kept private between your web server and the clients' web browsers.

The process of applying for a signed digital certificate begins with the generation and submission of a Certificate Signing Request (CSR) file.
The Certification Authority then checks and verifies the right to use the domain name in question.

Our Certificate reference manual will give you an extensive overview of the commands which can be submitted to the system.
The PDF of our certificate reference manual can be downloaded from the download area of the registrar admin section of the RRPproxy webinterface.

Please do not hesitate to contact us with your comments.

DV, OV, EV - Validation Types

There are three types of validation:

  • Domain authentication (DV) verifies that the applicant has administrative rights to the domain listed in the certificate. The verification is carried out via email, resource record in the DNS zone file, or a file on a web server. See also: Validation Methods
  • Full organization authentication (OV) includes business identity authentication, domain name verification and verification that the organizational contact applying for the certificate on behalf of the company or organization is an employee of that organization.
  • Extended Validation (EV) is the highest level of authentication (signed acknowledgement of agreement from the corporate contact is required). With Extended Validation, visitors see the address bar turn green when visiting the website in their browser, a visible sign that the site is highly authenticated, trustworthy and the customers' information is secure. However, there might be browsers out there that show a different behaviour.

Handling certificates and subs

The scheme in our SSL management is the separation of the general certificate data (like the certificate id, the domain name and the contacts) and the specific data of a certain instance of a certificate (we call it sub) like the CSR and CRT.

After each call of an Add-, Renew- or ReissueCertificate command, the response will return an order-identifier (parameter: certificate) and a certificate-identifier (parameter: sub). The StatusCertificate command will return the static data of an order and the dynamic data of the latest certificate (sub).

Thus the following scheme is applied:

Certificate (= order identifier, also referred to as certificate id)
- Sub1 (= certificate identifier, also referred to as sub or sub id)
- Sub2
- Sub3
...

Unlike domains SSL certificates can not be renewed. Instead, a new certificate will be issued. Following the principle of domain renewals RRPproxy provides the possibility to renew certificates. Issuing a renewal for a certificate will add a new sub to an order.

With this scheme you can keep your certificate id after a renew or reissue, but have technically unlimited renews / reissues and that you are able to look into older data from old certificates (parameter: sub) bundled to an order. This is extremely relevant if you e.g. need older CRT data after you just did a renew/reissue. In addition to giving you the option to look into older data, we also give you the option to use older data for a renew (eg. you need a renew with the data you used before a failed reissue).

Old Certificate IDs

With the introduction of our new SSL backend new certificate IDs have been assigned for all certificates in our system. The old IDs will not be used any more. A full list including old IDs and mapped new IDs of your certificates is available in the FTP area of your account which can be found in the web interface at “Account” -> “FTP”. Please regard, this list only exists as long as your account had certificates before we introduced the new SSL backend.


Available certificates

Below you find a link for of all certificates we offer:

https://www.rrpproxy.net/SSL_Certificates

SSL Multiyear Discounts

Multiyear Discounts are available for all SSL certificates and will automatically applied upon a multiyear registration. Please keep in mind that depending on the type of the respective certificate a maximum registration term of 2 years for EV (Extended Validated) or 3 years for DV (Domain Validated) and OV (Organisation Validated) certificates apply. Your pricing is available in the web interface of your account at “Account” -> “Zones & prices”.

SAN (Multidomain) Certificates

Support for SAN (Subject Alternative Name) is available for certain certificate products. Next to securing a domain name additional SANs can be secured with one single certificate. SANs are available for the following SSL certificates:

Geotrust True BusinessID: up to 24 additional SANs
Geotrust True BusinessID with EV: up to 24 additional SANs
Geotrust QuickSSL Premium: up to 3 additional SANs
Symantec Secure Site: up to 24 additional SANs
Symantec Secure Site Pro: up to 24 additional SANs
Symantec Secure Site with EV: up to 24 additional SANs
Symantec Secure Site Pro with EV: up to 24 additional SANs
Thawte SSL Web Server: up to 24 additional SANs
Thawte SSL Web Server with EV: up to 24 additional SANs

The full pricing is available in the web interface of your account at “Account” -> “Zones & prices”.

Please scroll down to Subject Alternative Names (SAN) for further technical information.


Certificate creation

How to Create a CSR

For ordering a certificate, you need to create a CSR (Certificate Signing Request) on your server. You may create such an CSR by issuing the following command using OpenSSL

   openssl req -new -nodes -newkey rsa:2048 -keyout www_example_com.key -out www_example_com.csr

Notes

  • The keyfile keeps your private key and should not be shown to anyone.
  • The key size should be equal to or greater than 2048.
  • The command name should be filled with the domainname to be used (No wildcard allowed).
  • The phone number for the owner contact has to be in the following format: +[country code] [local area code] [line number] (separated by blank spaces)
  • If you want to use mutated vowels (Umlaute) in your CSR, you have to add the parameter -utf8 to the command or update your openssl.cnf with utf8=Yes

Ordering process in Web Interface

  • Copy the complete content of the www_example_com.csr - file to the "AddCertificate" - command (Parameter CSR).
  • Fill in the contact - details (Please don't use contact handles with umlauts / special chars). Please also refer to Address/Place of Business Information Requirements
  • An email will be send to the approveremail with a link inside. This link ensures, that the requester is authorized to issue a certificate for your domain.
  • After validating, the certificate will be send via email to you and you can request it with the "StatusCertificate" - command.

Default Root Certificate for Symantec SSL Certificates

SSL Certificates of the Symantec family (Symantec / Thawte / Geotrust / RapidSSL) were signed by Symantec with their old SHA-1 RSA Root Certificate even if the SHA2-256 parameter was used. In order to comply with high security standards we introduced a bunch of further algorithms to choose from for certificate creation / renewal / reissue (Parameter: algorithm).

The default Root Certificate for SSL Certificates of the Symantec family (Symantec / Thawte / Geotrust / RapidSSL) will be changed to Symantec’s SHA2-256 RSA Root Certificate as of June 20 (Parameter: algorithm = SHA256-FULL-CHAIN).

Value Description
SHA2-256 SHA256 intermediate certificate with a SHA-1 RSA root certificate.
SHA256-FULL-CHAIN You can get certificates with a full SHA-256 certificate chain when the encryption algorithm is RSA. Compared to the default SHA2-256 option, which has a SHA-1 root, the SHA256-FULL- CHAIN option has a SHA-256 root.
SHA256-ECC-FULL Used with an ECC CSR, sets the certificate chain to an ECC certificate with an ECC root. Same behavior as SHA2-256 for ECC certificates.
SHA256-ECC-HYBRID Used with an ECC CSR, sets the certificate chain to an ECC certificate with an RSA root. This option provides the performance strength of ECC with the browser compatibility of the RSA root.
PRIVATE-SHA1-PCA3G1 PRIVATE-SHA1-PCA3G1 for Secure Site Pro only.
PRIVATE-SHA256-PCA3G1 PRIVATE-SHA256-PCA3G1 for Secure Site Pro only.
PRIVATE-SHA1-PCA3G2 PRIVATE-SHA1-PCA3G2 for Secure Site Pro only.
PRIVATE-SHA256-PCA3G2 PRIVATE-SHA256-PCA3G2 for Secure Site Pro only.

Command Examples:

AddCertificate:

[COMMAND]
Command=AddCertificate
...
ALGORITHM =
SHA2-256|SHA256-FULL-CHAIN|SHA256-ECC-FULL|SHA256-ECC-HYBRID|PRIVATE-SHA1-PCA3G1|
PRIVATE-SHA256-PCA3G1|PRIVATE-SHA1-PCA3G2|PRIVATE-SHA256-PCA3G2
...
EOF

RenewCertificate:

[COMMAND]
Command=RenewCertificate
...
ALGORITHM =
SHA2-256|SHA256-FULL-CHAIN|SHA256-ECC-FULL|SHA256-ECC-HYBRID|PRIVATE-SHA1-PCA3G1|
PRIVATE-SHA256-PCA3G1|PRIVATE-SHA1-PCA3G2|PRIVATE-SHA256-PCA3G2
...
EOF

ReissueCertificate:

[COMMAND]
Command=ReissueCertificate
...
ALGORITHM =
SHA2-256|SHA256-FULL-CHAIN|SHA256-ECC-FULL|SHA256-ECC-HYBRID|PRIVATE-SHA1-PCA3G1|
PRIVATE-SHA256-PCA3G1|PRIVATE-SHA1-PCA3G2|PRIVATE-SHA256-PCA3G2
...
EOF



Validation Methods

For Domain Validated certificate the validation is carried out by sending an email including approval link to the owner of the requested certificate. As soon as the owner clicks the link and thus approves the certificate is issued.
For Organisation Validated and Extended Validated certificates the respective Certificate Authority performs additional checks and callbacks to validate the certificate owner.

FILE and DNS validation are additional validation methods that only apply to Domain Validated SSL Certificates.


Symantec: FILE

  • To use the FILE based authentication for domain-vetted certificates, set the parameter "AUTHMETHOD" to "FILE" for AddCertificate", "RenewCertificate" and "ReissueCertificate"
[COMMAND]
(required)           
[COMMAND]  = 
command    = AddCertificate
csrX       = ...
[...]      = 
authmethod = FILE
EOF        = 
           
EOF
  • If the certificate class is valid for file based authentication, you will get two additional properties back:
[COMMAND]
(required)                               
[RESPONSE]                     = 
code                           = 200
description                    = Command completed successfully
runtime                        = 9.616
property[certificate][0]       = SA3546077
property[fileauth contents][0] = RInN0UIPzTzZrJDhCD6C
property[fileauth name][0]     = .well-known/pki-validation/fileauth.txt
property[status][0]            = REQUESTED
property[sub][0]               = SA3546077-001
property[sub status][0]        = ORDER_REQUESTED
EOF                            = 
                               
EOF
  • You need to use the properties "fileauth contents" and "fileauth name" as follows:
 In the root - domain (no sub-domain), create folders and file named as specified in "fileauth name" 
 Into the file, write the data returned in "fileauth contents" 
  • Symantec will poll this file and if it matches the data, the certificate will be generated. As an example, should the certificate above be for the domain "docs.example.com", the file created needs to be "example.com/.well-known/pki-validation/fileauth.txt" containing the string "RInN0UIPzTzZrJDhCD6C".

The FILE must always be stored at all main domains, not at sub-domains any more.

Only one FILE is necessary for the main domains.

For SAN SSL certificates, the FILE containing the string must be stated for all respective main domain(s), but not for sub-domains.

Exemplary domains in CSR
www.example.com
something.example.com
example.net
anotherthing.example.org
These require 3 FILEs at main domain level
example.com/.well-known/pki-validation/fileauth.txt
example.net/.well-known/pki-validation/fileauth.txt
example.org/.well-known/pki-validation/fileauth.txt

The content of the file is identical for these domains, it is generated of the CSR and only consists of the string returned via API.

Symantec: DNS

  • To use the DNS based authentication for domain-vetted certificates, set the parameter "AUTHMETHOD" to "DNS" for AddCertificate", "RenewCertificate" and "ReissueCertificate":
[COMMAND]
(required)           
[COMMAND]  = 
command    = AddCertificate
csrX       = ...
[...]      = 
authmethod = DNS
EOF        = 
           
EOF
  • If the certificate class is valid for DNS based authentication, you will get one additional property back:
[COMMAND]
(required)                          
[RESPONSE]                = 
code                      = 200
description               = Command completed successfully
runtime                   = 7.872
property[certificate][0]  = SA4317966
property[dnsauth name][0] = 20170727094628k5loo039okyyz1jlrde57ku091h1og39uv6enkzo1v265graqw
property[status][0]       = REQUESTED
property[sub][0]          = SA4317966-001
property[sub status][0]   = ORDER_REQUESTED
EOF                       = 
                          
EOF

The DNS record returned in the API response contains the date and a unique random string derived from the CSR and must be stored in a TXT - record:

example.com IN TXT 20170727094628k5loo039okyyz1jlrde57ku091h1og39uv6enkzo1v265graqw

The DNS record must always be stored at the main domain, not at sub-domains. For SAN SSL certificates, the TXT record for DNS based validation must be stated for all respective main domain(s), but not for sub-domains.

Exemplary domains in CSR
www.example.com
something.example.com
example.net
anotherthing.example.org
These require 3 TXT records at main domain level
example.com IN TXT <string>
example.net IN TXT <string>
example.org IN TXT <string>

The <string> is identical for these domains, it is generated of the CSR and is returned via API.


Comodo: Hash Generation

Important: As of July 20th 2017 the handling for FILE and DNS based validation for Comodo certificates has changed.

The biggest differences are:

  • Hashes need to be created using SHA-256 instead of SHA1
  • The directory for the file for FILE validation via HTTP(S) has changed to: /.well-known/pki-validation/

(Prior the file had to be stored at the root directory of the respective domain.)

  • A Random Hash has been introduced for all FILE and DNS based validation.
  • For DNS validation an underscore “_” as leading character and point “.” as separator has been introduced for the CNAME resource records.
  • The SHA-256 Hash needs to be interrupted with a point every 32 characters.

FILE and DNS based validation for Comodo certificates requires the creation of 2 different hashes in DER format:

  • SHA-256 of the CSR in DER (important!) format
  • MD5 of the CSR in DER (important!) format

These can be created using openssl:

cat server.csr | openssl req -outform DER | shasum -a 256
cat server.csr | openssl req -outform DER | md5sum

Comodo: FILE

Please note: Comodo FILE validation will fail if any redirection is used.

When using the Comodo FILE validation the CA will check for a file in the directory /.well-known/pki-validation/ of the respective domain.

To order Comodo SSL Certificates using FILE validation please set the respective parameter "AUTHMETHOD = FILE" in "AddCertificate", "RenewCertificate" and "ReissueCertificate" commands. The data necessary for FILE validation will be returned in the response of the respective command:

  • property[fileauth name][0]: MD5-Hash - The name of the File
  • property[fileauth contents][0]: SHA-256-Hash - the first line of the File
  • property[fileauth contents][1]: URL of the CA Comodo comodca.com - the second line of the File
  • property[fileauth contents][2]: random Hash - the third line of the File
[COMMAND]
Command=AddCertificate
…
AuthMethod=File
…
EOF
[RESPONSE]
code = 200
…
property[certificate][0] = CY2737994
property[fileauth name][0] = 8C7A3B5360E02F8C0EE6222D42345867.txt
property[fileauth contents][0] = 337c212a87093c4c06231b9c974eb848f29afaeb56f17ecb7ada84773779dca4
property[fileauth contents][1] = comodoca.com
property[fileauth contents][2] = 0466b86ba44e6ba5607a
property[status][0] = REQUESTED
property[sub][0] = CY2737994-001
property[sub status][0] = ORDER_REQUESTED 

Now perform the following steps to properly set up the file for validation:

  • Create a text file named <uppercase MD5>.txt (parameter: property[fileauth name]). Important: the file name containing the MD5 hash must be in uppercase!
  • In the first line of the file write the SHA-256 hash (parameter: property[fileauth contents][0])
  • In the second line, write "comodoca.com" (without quotation marks, parameter: property[fileauth contents][1])
  • In the third line insert the Random Hash (parameter: property[fileauth contents][2])
  • Put this file on the webserver in the directory /.well-known/pki-validation/

Example: mail.example.com
MD5 Hash(uppercase): 47CBA4DFBE697765F51230E84F04D091
SHA-256 Hash: 5b06bda4ffe784373d6616ab8fcbef17da4549f0623a25f37e128efb0fbf745d
Random Hash: 1f96729172445e721043

The file should be named "47CBA4DFBE697765F51230E84F04D091.txt" and contain the following lines:

5b06bda4ffe784373d6616ab8fcbef17da4549f0623a25f37e128efb0fbf745d
comodoca.com
1f96729172445e721043

To get a successful validation, the file needs to be reachable either on:

http://mail.example.com/.well-known/pki-validation/47CBA4DFBE697765F51230E84F04D091.txt

or

http://example.com/.well-known/pki-validation/47CBA4DFBE697765F51230E84F04D091.txt

After ordering the certificate you can check its status by issuing the StatusCertificate command. The data for FILE Validation will be returned as well.
Please note: The FILE contents are returned in property[fileauth contents] in one line. The contents in the File itself need to be line-by-line.

[COMMAND]
Command=StatusCertificate
Certificate=CY2737994
EOF
[RESPONSE]
property[certificate][0] = CY2737994
...
property[fileauth contents][0] = 337c212a87093c4c04681b9c974eb848f29afaeb56f17ecb7ada84773779dca4 comodoca.com 0466b86ba55e6ba5607a
property[fileauth name][0] = 8C7A3B5360E02F8C0EE6222D56215867.txt
...
property[status][0] = REQUESTED
...
EOF

Comodo: DNS

For this validation method you need to create a CNAME record in the DNS settings of your domain.

To order Comodo SSL Certificates using DNS validation please set the respective parameter "AUTHMETHOD = DNS" in "AddCertificate", "RenewCertificate" and "ReissueCertificate" commands. The data necessary for DNS validation will be returned in the response of the respective command:

  • property[fileauth contents][0]: the first line of the File, the SHA-256-Hash
  • property[fileauth contents][1]: the second line of the File, the URL of the CA Comodo comodca.com
  • property[fileauth contents][2]: the random Hash
  • property[fileauth name][0]: The name of the File, the MD5-Hash
[COMMAND]
Command=AddCertificate
…
AuthMethod=DNS
…
EOF
[RESPONSE]
code = 200
…
property[certificate][0] = CY2757994
property[fileauth contents][0] = 337c212a87093c4c06731b9c974eb848f29afaeb56f17ecb7ada84773779dca4
property[fileauth contents][1] = comodoca.com
property[fileauth contents][2] = 0466b26ba44e6ba5607a
property[fileauth name][0] = 8C7A3B5362E02F8C0EE6222D42345867.txt
property[status][0] = REQUESTED
property[sub][0] = CY2757994-001
property[sub status][0] = ORDER_REQUESTED 

Now perform the following steps to properly set up the file for validation:

  • Create a text file named <uppercase MD5>.txt. Important: the file name containing the MD5 hash must be in uppercase!
  • In the first line of the file write the SHA-256 hash.
  • In the second line, write "comodoca.com" (without quotation marks).
  • In the third line insert the Random Hash
  • Put this file on the webserver in the directory /.well-known/pki-validation/

Example: mail.example.com
MD5 Hash: 47cba4dfbe697765f51230e84f04d091
SHA-256 Hash: 5b06bda4ffe784373d6616ab8fcbef17da4549f0623a25f37e128efb0fbf745d
Random Hash: 1f96729172445e721043

Important:

  • The CNAME Record must begin with a leading underscore "_"
  • The SHA-256 Hash needs to be interrupted with a point every 32 characters. Additionally, the Random Hash needs to be separated with a point as well.

The new CNAME record should look as follows:

_47cba4dfbe697765f51230e84f04d091.mail.example.com.  CNAME  5b06bda4ffe784373d6616ab8fcbef1.7da4549f0623a25f37e128efb0fbf745d.1f96729172445e721043.comodoca.com.

After ordering the certificate you can check its status by issuing the StatusCertificate command. The data for DNS Validation will be returned as well.


[COMMAND]
Command=StatusCertificate
Certificate=CY2737994
EOF
[RESPONSE]
property[certificate][0] = CY2737994
...
property[fileauth contents][0] = 337c212a87093c4c04681b9c974eb848f29afaeb56f17ecb7ada84773779dca4 comodoca.com 0466b86ba55e6ba5607a
property[fileauth name][0] = 8C7A3B5360E02F8C0EE6222D56215867.txt
...
property[status][0] = REQUESTED
...
EOF


API Command reference


API Command Examples

GetCertificateInfo

Request general information about a certificate class:

[COMMAND]
command=GetCertificateInfo
class=<CLASS>

[RESPONSE]
property[class][0] = <CLASS>
property[dns auth][0] = 0|1
property[encyrption][0] = <MIN>-<MAX> bit[, optional more details]
property[extended validation][0] = 0|1
property[file auth][0] = 0|1
property[name][0] = <TEXT>
property[periods][0] = <COMMA-SEPERATED-INTEGERS>
property[prefix][0] = <2-CHAR-TEXT>
property[provider][0] = thawte|symantec|geotrust|rapidssl|comodo
property[reissue][0] = 0|1
property[revoke][0] = 0|1
property[san][0] = 0|1
property[validation method][0] = domain|organization|extended
property[wildcard][0] = 0|1

Command Examples:

[COMMAND]
command=GetCertificateInfo
class=QuickSSLPremium
EOF

[RESPONSE]
code = 200
description = Command completed successfully
property[class][0] = quicksslpremium
property[dns auth][0] = 1
property[encyrption][0] = 40-256 bit
property[extended validation][0] = 0
property[file auth][0] = 1
property[name][0] = Geotrust QuickSSL Premium
property[periods][0] = 1,2,3
property[prefix][0] = SI
property[provider][0] = GeoTrust
property[reissue][0] = 1
property[revoke][0] = 1
property[san][0] = 1
property[validation method][0] = domain
property[wildcard][0] = 0
EOF
[COMMAND]
command=GetCertificateInfo
class=SSLWebserverEV
EOF

[RESPONSE]
code = 200
description = Command completed successfully
queuetime = 0
runtime = 0.001
property[class][0] = sslwebserverev
property[dns auth][0] = 0
property[encyrption][0] = 128-256 bit
property[extended validation][0] = 1
property[file auth][0] = 0
property[name][0] = thawte SSL Webserver Certificate with Extended Validation (EV)
property[periods][0] = 1,2,3
property[prefix][0] = SD
property[provider][0] = thawte
property[reissue][0] = 1
property[revoke][0] = 1
property[san][0] = 1
property[validation method][0] = extended
property[wildcard][0] = 0

AddCertificate

This will create a new certificate order with its first sub-certificate.

[COMMAND]
command=AddCertificate
class=
csr#=
approveremail=<EMAIL>
period=<PERIOD>
ownercontact=<CONTACT>
admincontact=<CONTACT>
techcontact=<CONTACT>
billingcontact=<CONTACT>
webservertype=
domain=
(algorithm=)

[RESPONSE]
certificate=
sub=
certificate_status=
sub_status=

ReissueCertificate

This command will create a new sub-certificate in a certificate order (parameter "certificate") based on data of the most recent existing sub-certificate and the data given with the command (given values overwrite existing data). The expiration date of the new sub-certificate will not change since the new sub-certificate is only meant to be used as a replacement. Stating the CSR is mandatory. If you want to reissue the certificate order based on a different sub-certificate than the most recent, you have the option to use a specific sub-certificate (parameter "sub").

[COMMAND]
command=ReissueCertificate
certificate=
csr#=
(sub=) <-- only necessary, if data of an old sub-certificate shall be used.
(reissueemail=)
(algorithm=)

[RESPONSE]
certificate=
sub=
certificate_status=
sub_status=

RenewCertificate

As with the ReissueCertificate command, RenewCertificate will create a new sub-certificate in a certificate order (parameter "certificate") from the existing data of the most recent sub-certificate. The new sub-certificate will have a new expiration date based on the period given and it is not possible to change the CSR during a renew. If you want to renew the certificate based on a different sub-certificate than the most recent, you have the option to use a specific sub-certificate (parameter "sub").

[COMMAND]
command=RenewCertificate
certificate=
period=
(sub=)
(approveremail=)
(algorithm=)

[RESPONSE]
certificate=
sub=
certificate_status=
sub_status=

StatusCertificate

This command will give you all information about your certificate order (parameter "certificate") with all information about the latest sub-certificate. If you want to see the status of the certificate based on a different sub-certificate than the most recent, you have the option to use a specific sub-certificate (parameter "sub"). In addition to the order information, this command will return the metadata of the selected (most recent or given in the command) sub-certificate, a complete list of sub-certificates of the certificate order and the status for each sub-certificate. You also have the option to look into:

  • metadata encoded in the CSR and CRT
  • the intermediate certificate (property[intermediate crt][n])
  • the root certificate chain (property[root crt][n])
  • possible messages during the verification / authentification process using the wide=1 parameter (property[auth message][n])
  • a possible iconscript for the customers website (property[iconscript][n])
[command]
command=StatusCertificate
certificate=
(sub=)
(wide=0|1)
EOF

[RESPONSE]
property[admincontact][0]= 
property[approveremail][0]=
property[billingcontact][0]=
property[certificate][0]=
property[certificate expiration date][0]=
property[class][0]=
property[created date][0]=
property[crt][0]=
property[crt][1]=
...
property[crt][X]=
property[crt san][0]=
property[crt serial][0]=
property[crt size][0]=
property[csr][0]=
property[csr][1]=
...
property[csr][X]=
property[ownercontact][0]=
property[status][0]=
property[sub][0]=
...
property[sub][X]=
property[sub created date][0]=
property[sub id][0]=
property[sub updated date][0]=
property[sub status][0]=
...
property[sub status][X]=
property[techcontact][0]
property[updated date][0]
property[webservertype][0]


The following values are only returned if wide=1 is given in the command, please note, that not all properties are returned for every certificate - class:

property[auth message][n]=
property[crt authority key identifier][0]=
property[crt extended key usage][0]=
property[crt issuer][0]=
property[crt issuer commonname][0]=
property[crt issuer country][0]=
property[crt issuer organization][0]=
property[crt issuer organizational unit][0]=
property[crt key usage][0]=
property[crt key usage][1]=
property[crt key usage type][0]=
property[crt public key algorithm][0]=
property[crt signature algorithm][0]=
property[crt subject][0]=
property[crt validity not after][0]=
property[crt validity not before][0]=
property[csr commonname][0]=
property[csr country][0]=
property[csr location][0]=
property[csr organization][0]=
property[csr public key algorithm][0]=
property[csr signature algorithm][0]=
property[csr size][0]=
property[csr state][0]=
property[csr subject][0]=
property[iconscript][0]=
property[intermediate crt][n]=
property[domain][0]=
property[root crt][n]=
property[siteseal][0]=

Exemplary command output:

[COMMAND]
command = StatusCertificate
certificate = SI0000000
wide=1
EOF

[RESPONSE]
code = 200
description = Command completed successfully
property[admincontact][0] = P-KRG326                                                                                                                                                                                                                                
property[approveremail][0] = admin@domain.com
property[billingcontact][0] = P-KRG326
property[certificate][0] = P-SI0000000
property[certificate expiration date][0] = 2016-12-15 10:55:56
property[class][0] = quicksslpremium
property[created date][0] = 2015-12-14 18:00:08
property[crt][0] = -----BEGIN CERTIFICATE-----
property[crt][1] = MIIEYjCCA0qgAwIBAgIDAtBiMA0GCSqGSIb3DQEBCwUAMGYxCzAJBgNVBAYTAlVT
property[crt][2] = MRYwFAYDVQQKEw1HZW9UcnVzdCBJbmMuMR0wGwYDVQQLExREb21haW4gVmFsaWRh
property[crt][3] = dGVkIFNTTDEgMB4GA1UEAxMXR2VvVHJ1c3QgRFYgU1NMIENBIC0gRzQwHhcNMTUx
...
property[crt][22] = 7+ChOHkiG79DWXxsGI2F5Ll0wI+wB/uyVP+REkLmeZQ1DfH+OBAWd5B1zi1r+m3G
property[crt][23] = 479HcLtitQrpxSgZjvXZ/GQVPnogdepffMvw9GGWectkkY0GVNWKb5e1oH8PLypF
property[crt][24] = M3Zyv9lAQNYM4WZEh/N0iGScCLBvGA==
property[crt][25] = -----END CERTIFICATE-----
property[crt authority key identifier][0] = 0B:FF:EC:77:EF:AB:9B:FF:EC:03:A1:0A:FF:00:C6:4E:2A:18:C7:3E
property[crt extended key usage][0] = TLS Web Server Authentication
property[crt extended key usage][1] = TLS Web Client Authentication
property[crt issuer][0] = C=US, O=GeoTrust Inc., OU=Domain Validated SSL, CN=GeoTrust DV SSL CA - G4
property[crt issuer commonname][0] = GeoTrust DV SSL CA - G4
property[crt issuer country][0] = US
property[crt issuer organization][0] = GeoTrust Inc.
property[crt issuer organizational unit][0] = Domain Validated SSL
property[crt key usage][0] = Digital Signature
property[crt key usage][1] = Key Encipherment
property[crt key usage type][0] = critical
property[crt public key algorithm][0] = rsaEncryption
property[crt san][0] = www.domain.com
property[crt san][1] = domain.com
property[crt serial][0] = 132118 (0x2d123)
property[crt signature algorithm][0] = sha256WithRSAEncryption
property[crt size][0] = 2048
property[crt subject][0] = CN=www.domain.com
property[crt validity not after][0] = 2016-12-15 10:55:56
property[crt validity not before][0] = 2015-12-13 02:22:38
property[csr][0] = -----BEGIN CERTIFICATE REQUEST-----
property[csr][1] = MIIC9zCCAd8CAQAwgYgxCzAJBgNVBAYTAlNLMRgwFgYDVQQIDA9TbG92YWsgUmVw
property[csr][2] = dWJsaWMxDzANBgNVBAcMBktvc2ljZTEWMBQGA1UECgwNQUxFQVNFIHMuci5vLjEW
property[csr][3] = MBQGA1UEAwwNd3d3LmFsZWFzZS5ldTEeMBwGCSqGSIb3DQEJARYPYWRtaW5AYWxl
...
property[csr][15] = 3+/Jd0K0SrWwjq7+Roa7iB2jQzJA+HYTve5pd4B6SqwGE5VCWKcpU9wLN89XD4dc
property[csr][16] = N/Dzyu7ZoIlr0U7FcQ7I4T5dnonkIR1iZn62ZgUHhX6qLLEi8vRvw3sNnA==
property[csr][17] = -----END CERTIFICATE REQUEST-----
property[csr commonname][0] = www.domain.com
property[csr country][0] = DE
property[csr emailaddress][0] = admin@domain.com
property[csr key usage][0] = Digital Signature
property[csr key usage][1] = Non Repudiation
property[csr key usage][2] = Key Encipherment
property[csr location][0] = Sankt Ingbert
property[csr organization][0] = COMPANY INC.
property[csr public key algorithm][0] = rsaEncryption
property[csr signature algorithm][0] = sha256WithRSAEncryption
property[csr size][0] = 2048
property[csr state][0] = Germany
property[csr subject][0] = C=DE, ST=Germany, L=Sankt Ingbert, O=COMPANY INC., CN=www.domain.com/emailAddress=admin@domain.com
property[domain][0] = www.domain.com
property[iconscript][0] = <![CDATA[<!-- GeoTrust True Site[tm] Smart Icon tag. Do not edit. --> <SCRIPT LANGUAGE="JavaScript" TYPE="text/javascript"
                          SRC="//smarticon.geotrust.com/si.js"></SCRIPT>     <!-- end GeoTrust Smart Icon tag -->]]>
property[intermediate crt][0] = -----BEGIN CERTIFICATE-----
property[intermediate crt][1] = MIIERDCCAyygAwIBAgIDAjp4MA0GCSqGSIb3DQEBCwUAMEIxCzAJBgNVBAYTAlVT
property[intermediate crt][2] = MRYwFAYDVQQKEw1HZW9UcnVzdCBJbmMuMRswGQYDVQQDExJHZW9UcnVzdCBHbG9i
property[intermediate crt][3] = YWwgQ0EwHhcNMTQwODI5MjIyNDU4WhcNMjIwNTIwMjIyNDU4WjBmMQswCQYDVQQG
...
property[intermediate crt][22] = SGGFixD0wYi/f1+KwtfNK5RcHzRKCK/rromoSHVVlR27wJoBufQDIj7U5lIwDWe5
property[intermediate crt][23] = wJH9LUwwjr2MpQSRu6Srfw/Yb/BmAMmjXPWwj4PmnFrmtrnFvL7kAg==
property[intermediate crt][24] = -----END CERTIFICATE-----
property[ownercontact][0] = P-KRG326
property[root crt][0] = -----BEGIN CERTIFICATE-----
property[root crt][1] = MIIDVDCCAjygAwIBAgIDAjRWMA0GCSqGSIb3DQEBBQUAMEIxCzAJBgNVBAYTAlVT
property[root crt][2] = MRYwFAYDVQQKEw1HZW9UcnVzdCBJbmMuMRswGQYDVQQDExJHZW9UcnVzdCBHbG9i
property[root crt][3] = YWwgQ0EwHhcNMDIwNTIxMDQwMDAwWhcNMjIwNTIxMDQwMDAwWjBCMQswCQYDVQQG
...
property[root crt][17] = hw4EbNX/3aBd7YdStysVAq45pmp06drE57xNNB6pXE0zX5IJL4hmXXeXxx12E6nV
property[root crt][18] = 5fEWCRE11azbJHFwLJhWC9kXtNHjUStedejV0NxPNO3CBWaAocvmMw==
property[root crt][19] = -----END CERTIFICATE-----
property[status][0] = ACTIVE
property[sub][0] = P-SI0000000-001
property[sub created date][0] = 2015-12-14 18:00:08
property[sub id][0] = P-SI0000000-001
property[sub updated date][0] = 2015-12-14 19:21:00
property[sub status][0] = ACTIVE
property[techcontact][0] = P-KRG326
property[updated date][0] = 2015-12-14 19:21:00
property[webservertype][0] = apacheapachessl
EOF

Examples for notices from Symantec regarding the verification/authentification process:

property[auth message][0] = Pollresp: AUTHENTICATED via FILE (last polled 2016-08-23T09:08:21+00:00)

or

property[auth message][0] = Pollresp: ENTRY_NOT_FOUND via DNS (last polled 2015-09-17T07:40:36+00:00)

or

property[auth message][0] = DOMAIN_VERIFICATION: COMPLETED (2016-08-08T08:55:03+00:00)
property[auth message][1] = ORGANIZATION_VERIFICATION: COMPLETED (2016-08-08T08:55:03+00:00)
property[auth message][2] = VERIFICATION_CALL: COMPLETED (2016-08-08T08:55:03+00:00)

or

property[auth message][0] = DOMAIN_VERIFICATION: COMPLETED(2016-08-31T12:55:06+00:00)
property[auth message][1] = ORGANIZATION_VERIFICATION: COMPLETED(2016-08-30T09:06:23+00:00)
property[auth message][2] = VERIFICATION_CALL: ATTEMPTED_TO_REACH_CUSTOMER(2016-08-31T13:01:26+00:00)
property[auth message][3] = 2016-08-31T00:00:00+00:00: A telephone verification call is required before the certificate is issued. Customer Support was unable to reach the 
			    Corporate Contact by dialing +1 234 567 890. This telephone number was listed under the confirmed company name and address, in a public, approved
                            third party telephone directory, such as duns, and must be used for the verification call unless an alternative number can be found through an
                            approved third party directory. To schedule the verification call, please contact Customer Support. If the telephone number is invalid, you can update
			    the telephone number with the above-mentioned directory or complete the Professional Opinion Letter (POL). To discuss the POL Template or other options,
                            please contact Customer Support. Please check your e-mail for more information. Thank you.

Please note: The texts are directly from Symantec and don't necessarily have to be in english, depending on the contact they can be in a different language.

QueryCertificateList

Listing all certificate orders is possible with the QueryCertificateList command. This behaves like most Query...List - commands in RRPproxy allowing filtering and paging. By default all cancelled certificates are not returned.

[command]
command=QueryCertificateList
(wide=0|1)
(limit=<INT>)
(first=<INT>)
EOF


Workflow Examples

Short description of different commands for certificates and subs.

AddCertificate

Ordering a new certificate. Creates a new certificate and a new sub.

[command]
command=AddCertificate
csrX=...
[...]

Certificate before the command has been issued:

n/a

Certificate after the command has been issued:

Certificate:		CZ00001
Sub:			CZ00001-001		ACTIVE

RenewCertificate

Renewing an existing certificate. Mandatory parameter is "certificate", a certain sub can be stated optionally. Creates a new sub for an existing certificate.

  • Example 1:
[Command]
command=RenewCertificate
certificate=CZ00001

--> No sub has been explicitly stated, the newest active certificate will be renewed.
Certificate before the command has been issued:

Certificate:		CZ00001
Sub:			CZ00001-001		ACTIVE	<-- this sub will be renewed

Certificate after the command has been issued:

Certificate:		CZ00001
Sub:			CZ00001-001		ACTIVE
Sub:			CZ00001-002		ACTIVE	<-- this is the renewed sub


  • Example 2:
[Command]
command=RenewCertificate
certificate=CZ00001

--> No sub has been explicitly stated, the newest active certificate will be renewed.
Certificate before the command has been issued:

Certificate:		CZ00001
Sub:			CZ00001-001		ACTIVE
Sub:			CZ00001-002		ACTIVE	<-- this sub will be renewed

Certificate after the command has been issued:

Certificate:		CZ00001
Sub:			CZ00001-001		ACTIVE
Sub:			CZ00001-002		ACTIVE
Sub:			CZ00001-003		ACTIVE	<-- this is the renewed sub


  • Example 3:
[Command]
command=RenewCertificate
certificate=CZ00001
sub=CZ00001-001

--> The explicitly stated sub will be renewed.
Certificate before the command has been issued:

Certificate:		CZ00001
Sub:			CZ00001-001		ACTIVE	<-- this sub will be renewed
Sub:			CZ00001-002		ACTIVE

Certificate after the command has been issued:

Certificate:		CZ00001
Sub:			CZ00001-001		ACTIVE
Sub:			CZ00001-002		ACTIVE
Sub:			CZ00001-003		ACTIVE	<-- this is the renewed sub

ReissueCertificate

  • Example 1:
[Command]
command=ReissueCertificate
certificate=CZ00001
csrX=...

--> No sub has been explicitly stated, the newest active certificate will be reissued.
Certificate before the command has been issued:

Certificate:		CZ00001
Sub:			CZ00001-001		ACTIVE	<-- this sub will be reissued

Certificate after the command has been issued:

Certificate:		CZ00001
Sub:			CZ00001-001		ACTIVE
Sub:			CZ00001-002		ACTIVE	<-- this is the reissued sub


  • Example 2:
[Command]
command=ReissueCertificate
certificate=CZ00001
csrX=...

--> No sub has been explicitly stated, the newest active certificate will be reissued.
Certificate before the command has been issued:

Certificate:		CZ00001
Sub:			CZ00001-001		ACTIVE
Sub:			CZ00001-002		ACTIVE	<-- this sub will be reissued

Certificate after the command has been issued:

Certificate:		CZ00001
Sub:			CZ00001-001		ACTIVE
Sub:			CZ00001-002		ACTIVE
Sub:			CZ00001-003		ACTIVE	<-- this is the reissued sub


  • Example 3:
[Command]
command=ReissueCertificate
certificate=CZ00001
sub=CZ00001-001
csrX=...

--> The explicitly stated sub will be reissued.
Certificate before the command has been issued:

Certificate:		CZ00001
Sub:			CZ00001-001		ACTIVE	<-- this sub will be reissued
Sub:			CZ00001-002		ACTIVE

Certificate after the command has been issued:

Certificate:		CZ00001
Sub:			CZ00001-001		ACTIVE
Sub:			CZ00001-002		ACTIVE
Sub:			CZ00001-003		ACTIVE	<-- this is the reissued sub

DeleteCertificate

The DeleteCertificate command can be used to revoke a certificate.

  • Example 1:
[Command]
command=DeleteCertificate
certificate=CZ00001

--> No sub has been explicitly stated, the newest active certificate will be revoked.
Certificate before the command has been issued:

Certificate:		CZ00001
Sub:			CZ00001-001		ACTIVE
Sub:			CZ00001-002		ACTIVE	<-- this sub will be revoked

Certificate after the command has been issued:

Certificate:		CZ00001
Sub:			CZ00001-001		ACTIVE
Sub:			CZ00001-002		REVOKED


  • Example 2:
[Command]
command=DeleteCertificate
certificate=CZ00001
sub=CZ00001-001

--> The explicitly stated sub will be reissued.

Certificate before the command has been issued:
Certificate:		CZ00001
Sub:			CZ00001-001		ACTIVE	<-- this sub will be revoked
Sub:			CZ00001-002		ACTIVE

Certificate after the command has been issued:

Certificate:		CZ00001
Sub:			CZ00001-001		REVOKED
Sub:			CZ00001-002		ACTIVE


Subject Alternative Names (SAN)

To add additional domains to a certificate, please use the SAN - extension for a CSR AND submit the required domains in the AddCertificate/ReissueCertificate - command. The domains submitted via command and included in the CSR will be compared and any difference will result in a failing request. The order of domains is not important and the matching is not case-sensitive. You can use the CheckCertificate command to check the SAN in your CSR.
Note: Certificates containing SAN will be charged by the number of additional domains

Note: We don't support changing of SAN in existing certificates at the moment

[COMMAND]
command=AddCertificate
csrX=...
[...]
domain0=example.net
domain1=www.example.net
domain2=www.example.com
domain3=mail.example.com
EOF

Generating a CSR including SAN with OpenSSL

To create a CSR containing SAN with OpenSSL, you need to create a config containing the "alt_names" - extension as shown below (using example.cnf)

HOME                    = .
RANDFILE                = $ENV::HOME/.rnd

[req]
default_bits            = 2048
default_keyfile         = privkey.pem
distinguished_name      = req_distinguished_name
attributes              = req_attributes
x509_extensions         = v3_req
string_mask             = nombstr
req_extensions          = v3_req
default_md = sha256

[req_distinguished_name]
countryName                     = Country Name (2 letter code)
countryName_default             = DE
countryName_min                 = 2
countryName_max                 = 2

stateOrProvinceName             = State or Province Name (full name)
stateOrProvinceName_default     = Test state

localityName                    = Locality Name (eg, city)
localityName_default            = Test town

0.organizationName              = Organization Name (eg, company)
0.organizationName_default      = Testing Ltd.

organizationalUnitName          = Organizational Unit Name (eg, section)
organizationalUnitName_default  = Test department

commonName                      = Common Name (eg, YOUR name)
commonName_max                  = 64
commonName_default              = www.example.com

emailAddress                    = Email Address
emailAddress_max                = 64
emailAddress_default            = hostmaster@example.com

[v3_req]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = example.net
DNS.2 = www.example.net
DNS.3 = www.example.com
DNS.4 = mail.example.com

This file can now be used with this openssl command to create a new CSR:

openssl req -new [-nodes] [-sha256] -keyout example.key -out example.csr -config example.cnf

The resulting content of example.csr can then be used in CheckCertificate, AddCertificate or ReissueCertificate by using the CSR# parameter (every line in the CSR a new numbered parameter).

Ordering a certificate with Subject Alternative Names

To include multiple domains in 1 certificate, Subject Alternative Names (SAN) can be used. For this, the domainX - parameters must match the SAN - extension in the CSR (See details in the introduction).

[COMMAND]
command=AddCertificate
csr0=-----BEGIN CERTIFICATE REQUEST-----
csr1=MIIC9DCCAdwCAQAwga4xCzAJBgNVBAYTAkRFMRswGQYDVQQIExJSaGluZWxhbmQt
csr2=UGFsYXRpbmUxFDASBgNVBAcTC011c3RlcnN0YWR0MRQwEgYDVQQKEwtNdXN0ZXJm
csr3=aXJtYTEdMBsGA1UECxMUVGVjaG5pY2FsIGRlcGFydG1lbnQxFDASBgNVBAMTC2V4
csr4=YW1wbGUuY29tMSEwHwYJKoZIhvcNAQkBFhJtdXN0ZXJAZXhhbXBsZS5jb20wggEi
csr5=MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDNfuchcGp4dbz++86IT9dhN9DT
csr6=Wt3ll8bDlLBkntHVIUcBPNl0QwX3WSM1Oc1Xf8VuDvk8ywlj0KC8kEtBMdwDBONg
csr7=K+c0QcXTjebFd5Az5ExUiAytUvficVccDzpPIojcht4/pZoYtwDA7ZLxegT50fe6
csr8=qiFUkT1O9NGIZIfHooh2wFzRN92UXb2L08zuNv6+He6OAPoAA9JgmlY+MDD0Nwrj
csr9=n6dWKv8RZ8ffBLevdKivYMvZWD+z5FF/T43UMQ2Zu+4oYYx/o2Zq0IKormHGTydq
csr10=h1Cxy4zmhdRYkY/ISXDhUrZB/PNL30eWnUQrOk074jrAw+27HtFI1iTaVXwPAgMB
csr11=AAGgADANBgkqhkiG9w0BAQUFAAOCAQEAjr3iAQIYN2F3XFj2t3x818wLbmnIkuL3
csr12=KW96PfGs/c6IQbLcdauPrLly+rZIWwic0/TKgGV3A9mQM/V2Bip6b50l7AEWSdiL
csr13=8wq3B9kQN24XA19E0YtILuBBFIcnAEvB70xWKdYn1y0gBnepgIGJ56ecxpFK2QBY
csr14=3flMV6puvRIXatB4g6UeEO4aekBsVnPC8wIQSn6ioZ5SOlzXGHOtE5deuJt4LMtn
csr15=KNaA4vhGW3ogflle4Dnf9HILsd41KNfOLS+f2adBq6eXJpAydVbEHW2qU9/TNGHK
csr16=imMq0DwFaRVWh29FKXqEFJJN5KjtGfCoKj9rIC/TOMgeq+2XIUyxzA==
csr17=-----END CERTIFICATE REQUEST-----
approveremail=muster@example.com
ownercontact0=P-ABC1
admincontact0=P-ABC1
techcontact0=P-ABC1
billingcontact0=P-ABC1
webservertype=apache2
class=TRUEBIZID
domain0=example.net
domain1=www.example.net
domain2=www.example.com
domain3=mail.example.com
EOF
[RESPONSE]
code = 200
description = Command completed successfully
property[billingclass][0] = truebizid-4san
property[certificate][0] = SA1234567
property[status][0] = REQUESTED
property[sub][0] = SA1234567-001
property[sub status][0] = ORDER_REQUESTED
EOF


Certificates

Symantec, Thawte, GeoTrust and RapidSSL

  • Since April 1, 2015 the maximum duration of these certificate types is limited to 3 years.

Additional "RapidSSL Intermediate CAs" can be downloaded directly from RapidSSL through the knowledgebase.

Comodo

  • From March 29, 2015the maximum duration of these certificate types will limited to 3 years
  • DeleteCertificate (Revoke) for Comodo certificates has to be handled manually by our support team. Please send an email to: support@rrpproxy.net

CAA records

As of now KeyDNS is capable of managing CAA records via API and in our RRPproxy web interface.

The purpose of the CAA (Certification Authority Authorization) record is to allow domain owners to specify which certificate authorities are allowed to issue a SSL certificate for a domain. If no CAA record is present, any CA is allowed to issue a certificate for the domain. If a CAA record is present, only the CAs listed in the record(s) are allowed to issue certificates for that host name. Thus a CAA record is optional for customers to set, but mandatory for certificate authorities to check.

For reference: RFC 6844 for CAA records https://tools.ietf.org/html/rfc6844

API Command Examples

Allow the Certificate Authority Symantec to issue SSL certificates for example.com:

[COMMAND]
command = adddnszone
dnszone = example.com
rr0 = @ IN CAA 0 issue symantec.com

Allow the Certificate Authority Symantec to issue SSL wildcard certificates for example.com:

[COMMAND]
command = modifydnszone
dnszone = example.com
rr0 = @ IN CAA 0 issuewild symantec.com

Allow the Certificate Authority Symantec to issue SSL wildcard certificates for example.com, but disallow single domain SSL certificates:

[COMMAND]
command = modifydnszone
dnszone = example.com
rr0 = @ IN CAA 0 issue ";"
rr1 = @ IN CAA 0 issuewild symantec.com


Define email address to send incident reports to:

[COMMAND]
command = modifydnszone
dnszone = example.com
rr0 = @ IN CAA 0 iodef mailto:info@example.com


Define URL to send incident reports to:

[COMMAND]
command = modifydnszone
dnszone = example.com
rr0 = @ IN CAA 0 iodef http://www.example.com/script.php

Note: There's currently no standard format for receiving incident reports. And it might not be supported by all Certificate Authorities.

Certificate Authorities offered at RRPproxy

  • Symantec: symantec.com
  • Thawte: thawte.com
  • Geotrust: geotrust.com
  • RapidSSL: rapidssl.com
  • Comodo: comodoca.com


Certificate Authority used by our RRPproxy hosting (HOMER)

  • Let's Encrypt: letsencrypt.org

Special Information

Approver E-Mail Address

Allowed prefixes for the approver e-mail address are:

  • admin@
  • administrator@
  • hostmaster@
  • webmaster@
  • postmaster@

Furthermore, the domain part of the approver e-mail address must be identical with the domain which you want to create a certificate for.

For example:
admin@example.com is a valid approver e-mail address in order to buy a SSL certificate for the domain www.example.com.
If an appropriate e-mail address does not exist, it must be created.

Extended Validation (EV) Certificates

  • For Extended Validation (EV) Certificates, the respective Certificate Authority (CA) will check some databases to verify the contact information. Please find example databases below:

National (Germany)

International

Netherlands

Renew of SHA1 certificates

  • SHA1 hashing algorithm is not supported if certificate validity end date is beyond 12/31/2016.

SHA-2 as default, multi-year options reduced, internal domains

1. Changeover from SHA-1 to SHA-2
The previously used Secure Hash Algorithmus SHA-1 is not regarded as totally secure anymore. Google and Microsoft decided to reject SSL certificates using SHA-1 in the future and to denote them in their browsers as „not secure". All websites with SSL certificates expiring after December 31, 2015 and using SHA-1 are affected by this devaluation. To avoid that these derogatory indicators are shown to online users with e.g. Chrome version 39, SHA-1 SSL certificates expiring after December 31, 2015, should be substituted by SHA-256 (SHA-2)-certificates.

As of November 3, 2014 all new SSL certificates from Symantec, thawte, GeoTrust and RapidSSL issued by RRPproxy will therefore by default be signed with algorithm SHA-2, which is regarded as more secure. Comodo products are already signed with SHA-2. For already issued certificates the changeover from SHA-1 to SHA-2 can be enforced by using the parameter "ALGORITHM = SHA2-256" in the command ReissueCertificate.The reissuing of the certificate is not associated with any costs. If you want to maintain SHA-1 for new certificates, you can restore the default setting with the parameter "ALGORITHM = SHA1".

Example for ReissueCertificate:

[COMMAND]
(required)            
command     = ReissueCertificate
certificate = fr86fr8r68fe6r8vfze5z
csr0        = -----BEGIN CERTIFICATE REQUEST-----
csr1        = MIIE4TCCAskCAQAwgZsxCzAGUOBAYTAkRFMQwwCgYDVQQIDANOUlcxFjAUBgNV
[...]       = 
csr28       = -----END CERTIFICATE REQUEST-----
algorithm   = SHA2-256
            
EOF

2. The maximum duration of SSL certificates will be reduced.
From April 1, 2015 and for Comodo certificates already from March 29, 2015 the maximum term of SSL certificates is limited to three years.

3. SSL certificates for internal domain names can not be ordered any more since November 1st, 2014.
Based on a decision of the CA/Browser Forum in 2012 SSL certificates for securing local domains, IP addresses or server names (internal names such as .local, .intra, .intern) with an expiration date later than November 1, 2015 are no longer valid. From October 1, 2016 such SSL certificates will be completely taken off the market. At that point in time all still valid SSL certificates with internal domain names will be revoked by the certification authorities and thus invalid. One reason for this decision is the introduction of new gTLDs and the risk of a name collision between internal and public domains using the new gTLDs.

Address/Place of Business Information Requirements

CA/Browser Forum Ballot 191 clarifies address/place of business information requirements in certificates – specifically, the state/province and locality fields.

In accordance with Ballot 191, our system will allow users to enter either locality or state/province when only one is applicable. It is recommended that users provide locality and state/province when both exist.

Note: These requirements apply only to OV and EV SSL/TLS and code signing certificates.

Note that our systems will continue to require values in both locality and state/province fields in the following countries:

Country Country Code
Afghanistan AF
Algeria DZ
Argentina AR
Australia AU
Brazil BR
Canada CA
China CN
Ecuador EC
Federated States of Micronesia FM
Germany DE
India IN
Indonesia ID
Italy IT
Korea (South) KR
Madagascar MG
Malaysia MY
Mexico MX
Mongolia MN
Myanmar MM
Pakistan PK
Philippines PH
Poland PL
Sierra Leone SL
Solomon Islands SB
South Africa ZA
Spain ES
Sri Lanka LK
Switzerland CH
Thailand TH
United Arab Emirates AE
United States of America US
User Assigned ISO Code XX
Vietnam VN
Personal tools
Namespaces

Variants
Actions
Resources
new gTLDs
Products
New Users
General
Tools