1. How does PIR control access to the Shared Registry System (SRS)?
2. How do I specify the IP addresses that can access the SRS?
3. What is a Secure Socket Layer (SSL) certificate?
4. Where do I get an SSL certificate?
5. Which SSL toolkit should I use?
6. Which cipher suites are accepted?
7. When do I get the username/password for the Production SRS?
8. What is the requirement for the purpose of “SSL Client:YES”for the SSL certificate I purchase?


1. How does PIR control access to the Shared Registry System (SRS)?
Access to the SRS is restricted by three mechanisms:

• Access control to the Production SRS is restricted by IP address filters.
• SSL encryption is required for the communication channels between the registrar's client system and the OT&E and production systems.
• Authentication by means of a username and password is required for session establishment.

The SRS requires the correct combination of the three mechanisms for each registrar before access is granted.

2. How do I specify the IP addresses that can access the SRS?
The Registrar Data Form has a section where registrars may specify the IP subnets that will be accessing the Production SRS. If you wish to change the IP subnets after this form has been submitted, please follow the .ORG IP Subnet Change Request process. The specified subnets must conform to the following rules:

• A maximum of three IP subnets.
• A maximum of 96 hosts between the three IP subnets.
• The ranges must be written in CIDR format (e.g., 192.168.1.0/27 where the "/27" represents the length of the subnet). We cannot accept any ranges below a /26 range (i.e., /25, /24, etc). CIDR format dictates the number of hosts within each range. The ranges are as follows:
  • /26 = 64 hosts.
  • /27 = 32 hosts.
  • /28 = 16 hosts.
  • /29 = 8 hosts.
  • /30 = 4 hosts.
  • /31 = 2 hosts.
  • /32 = 1 host.
• Examples of valid subnets include:
  • One subnet of 64 hosts (e.g., 192.168.1.0/26).
  • One subnet of 64 hosts and one subnet of 32 hosts or less (e.g., subnet #1 as 192.168.2.0/26, which represents 64 addresses 192.168.2.0 to 192.168.2.63; and subnet #2 as 192.168.3.0/27, which represents 32 addresses 192.168.3.0 to 192.168.3.31).
  • Three subnets of 32 hosts or less (e.g., subnet #1 as 192.168.2.0/27, which represents 32 addresses 192.168.2.0 to 192.168.2.31; subnet #2 as 192.168.3.0/27, which represents 32 addresses 192.168.3.0 to 192.168.3.31; and subnet #3 as 192.168.4.0/27, which represents 32 addresses 192.168.4.0 to 192.168.4.31).
• The specified subnets must fall on valid bit boundaries. For example, a subnet specified as 192.168.2.1/27 is not acceptable because ".1" is not a valid boundary for a /27 subnet. The following table defines the valid boundaries for each subnet length.

Length of Subnet	Number of Hosts	Boundaries
/26	64	0,64,128,192
/27	32	0,32,64,96,128,160, 192,224
/28	16	0,16,32,48,64,80, 96,112,128,144, 160,176,192,208, 224,240
/29	8	0,8,16,24,32,40,...,248 (in increments of 8)
/30	4	0,4,8,12,16,20,...,252 (in increments of 4)
/31	2	0,2,4,6,8,12,...,254 (in increments of 2)
/32	1	0 through 255 (in increments of 1)

3. What is a Secure Socket Layer (SSL) certificate?
A digital certificate is simply a statement digitally signed by an independent and trusted third party (the certificate authority). That statement usually follows a very specific format laid down in a standard called X.509; hence, they are sometimes referred to as X.509 certificates.

A certificate is required to establish an authenticated and encrypted communications channel between the registrar's server and .ORG SRS.

4. Where do I get an SSL certificate?
X.509 SSL certificates can be obtained from one of the accepted Certificate Authorities. Please make sure that the certificate you obtain is NOT an individual/personal certificate. The accepted Certificate Authorities are Verisign and Thawte. If you would like to use a Certificate Authority that is not on this list, please contact Tech Support.

Please refer to Question 8 for more specific details about the certificate to purchase.

5. Which SSL toolkit should I use?
Registrars are responsible for obtaining an SSL toolkit that is compatible with the development language and platform of their client system. The minimum requirement is that it must support SSL version 3.

For C, C++ or Perl, OpenSSL is an open-source SSL solution.

For Java:

• Sun's Java Secure Socket Extension.
• SSLava from Phaos Technology. SSLava also is the toolkit used in the development of the SRS.

6. Which cipher suites are accepted?
To establish an SSL connection to the SRS, the registrar's client system must choose a cipher suite supported by the SRS. The SRS supports the following ciphers:

• SSL_RSA_WITH_DES_CBC_SHA
• SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
• SSL_RSA_WITH_3DES_EDE_CBC_SHA
• SSL_RSA_WITH_RC4_128_SHA
• SSL_RSA_WITH_RC4_128_MD5
• SSL_RSA_EXPORT_WITH_RC4_40_MD5
• SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
• SSL_DHE_RSA_WITH_DES _CBC_SHA
• SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA

7. When do I get the username/password for the Production SRS?
The username and password for the Production SRS is issued after you have successfully completed OT&E certification and all business requirements.

8. What is the requirement for the purpose of “SSL Client:YES”for the SSL certificate I purchase?
This defines the purpose of the certificate and whether it can be used as client certificate. The following is a sample of an expected output from the command: openssl x509 -in your_cert.filename -purpose

Certificate purposes:

• SSL client : Yes
• SSL client CA : No
• SSL server : Yes
• SSL server CA : No
• Netscape SSL server : Yes
• Netscape SSL server CA : No
• S/MIME signing : No
• S/MIME signing CA : No
• S/MIME encryption : No
• S/MIME encryption CA : No
• CRL signing : Yes
• CRL signing CA : No
• Any Purpose : Yes
• Any Purpose CA : Yes
• OCSP helper : Yes
• OCSP helper CA : No

Please ensure that the certificate you purchase has “YES” for SSL client. As noted, this certificate can be used for both server and client purposes.