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)

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).
  • 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


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


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.

Validation Methods

Attention: FILE and DNS validation method now also available for Comodo SSL Certificates.

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]     = ckz1vq30.htm
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 - directory for the domain, create a 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 "example.com", the file created needs to be "example.com/ckz1vq30.htm" containing the string "RInN0UIPzTzZrJDhCD6C".

Upcoming changes for Symantec FILE validation as of March 15th

The string returned in the API response is longer than 32 characters, a file named and located at <domain>/.well-known/pki-validation/fileauth.txt containing only the string must be used.

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 two additional properties back:
[COMMAND]
(required)                          
[RESPONSE]                = 
code                      = 200
description               = Command completed successfully
runtime                   = 7.872
property[certificate][0]  = SA4317966
property[dnsauth name][0] = sm14c8le2x6c2am17p0b9knfk5w4rm78.example.com
property[status][0]       = REQUESTED
property[sub][0]          = SA4317966-001
property[sub status][0]   = ORDER_REQUESTED
EOF                       = 
                          
EOF
  • You need to use the property "dnsauth name" as follows:
 * Create a CNAME in the zonefile for the domain as specified in "dnsauth name" 
 * Point the CNAME to a timestamped entry formatted "s<YYYYMMddHHmmss>.example.com" 
  • The timestamp needs to be within 24 hours of the current time to be accepted.
  • Symantec will poll the entry specified via "dnsauth name" and if the timestamp matches, the certificate will be generated. As an example, should the certificate above be for the domain "example.com", the following dns entries need to be created:
sm14c8le2x6c2am17p0b9knfk5w4rm78.example.com as CNAME to s20150401123456.example.com
s20150401123456.example.com as A <serverip>

Upcoming changes for Symantec DNS based validation as of March 15th

The DNS record returned in the API response is longer than 32 characters and a TXT record must be used. After the transition, only TXT records will be valid. The DNS record must always be stored at the main domain, not at sub-domains any more. 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: FILE

To automatically create comodo - certificates, 2 hashes are needed:

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

These can be created with the following commands:

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

Now do the following steps before ordering the certificate:

  • Create a textfile named <uppercase MD5>.txt
  • Write the SHA-1 hash into the file
  • In a second line, write "comodoca.com"
  • Put this file o the webserver directly in the FQDN or directly under the domain

Example: mail.example.com MD5 (uppercase): 47CBA4DFBE697765F51230E84F04D091 SHA-1: 900d8d7622df02a69a855cfbdb749d1181bbff65

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

900d8d7622df02a69a855cfbdb749d1181bbff65
comodoca.com

To get a successful validation, the file needs to be reachable either on "http://mail.example.com/47CBA4DFBE697765F51230E84F04D091.txt" or "http://example.com/47CBA4DFBE697765F51230E84F04D091.txt"

Now you can order the certificate with "AUTHMETHOD = FILE" in "AddCertificate", "RenewCertificate" and "ReissueCertificate":

[COMMAND]
command=AddCertificate
csrX=...
[...]
authmethod=FILE
EOF

Please note: opposed to the FILE based authentication with Symantec, the properties will be returned, but need to be set before the command is issued. They are returned only for verification - purposes.


Comodo: DNS

To automatically create comodo - certificates, 2 hashes are needed:

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

These can be created with the following commands:

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

Now do the following steps before ordering the certificate:

  • Create a new CNAME record: <MD5>.example.com. CNAME <SHA-1>.comodoca.com

Example: mail.example.com MD5 (uppercase): 47CBA4DFBE697765F51230E84F04D091 SHA-1: 900d8d7622df02a69a855cfbdb749d1181bbff65

The new CNAME - record should look as follows:

47cba4dfbe697765f51230e84f04d091.mail.example.com.  CNAME  900d8d7622df02a69a855cfbdb749d1181bbff65.comodoca.com.

Now you can order the certificate with "AUTHMETHOD = DNS" in "AddCertificate", "RenewCertificate" and "ReissueCertificate":

[COMMAND]
command=AddCertificate
csrX=...
[...]
authmethod=DNS
EOF

Please note: opposed to the DNS based authentication with Symantec, the same property will be returned, but it needs to be set before the command is issued. It is only returned for verification - purposes.

Personal tools
Namespaces

Variants
Actions
Resources
new gTLDs
Products
New Users
General
Tools