dotMobimobiThinkingmobiForgemobiReadyDeviceAtlasgoMobi

Registrar Security FAQ

Q: How does mTLD control access to the Shared Registry System?

A: Access to the Shared Registry System is restricted by three mechanisms:

  • Access control to the production SRS is restricted by IP address filters. Registrars can access the registry only from designated IP ranges.
  • 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.

Q: How do I specify the IP addresses that can access the SRS?

A: The Registrar Data Form has a section where you can specify the IP subnets that will be accessing the production SRS. The specified subnets must conform to the following rules:

For the IP subnets, each registrar may specify:

  • A maximum of 3 subnets.
  • A maximum of 96 IP addresses between the two subnets.
  • Subnets must be specified in CIDR format (e.g. 192.168.1.0/27) where the "/27" represents the length of the subnet. The limitation on the maximum of 64 IP addresses means that the length will never be less than /26.
  • IP addresses must be static.
  • 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, 48, …, 248 (in increments of 8)
/30 4 0, 4, 8, 12, 16, 20, 24, 28, …, 252 (in increments of 4)
/31 2 0, 2, 4, 6, 8, 12, 14, 16, 18, …, 254 (in increments of 2)
/32 1 0 through 255

Registry IP Subnet Change Policies

  • Your IP addresses must be static.
  • Up to three (3) IP Subnets for EPP: 700.
  • Registrar must allow up to two (2) business days for the IP subnet add/delete/change to be implemented by Technical Support. Therefore, we request that you plan your changes with us in advance. If the request is not received in a proper format, it may take longer for us to authorize your access.
  • If the request is not received with all required information, the implementation of add/delete/change may require additional time to process.
  • Registrar should follow the instructions below and verify that the IP Subnets are in correct CIDR format.
  • Registrar should contact Tech Support (in writing) with its request. When it becomes available, registrars can also utilize the Registrar IP Subnet Add/Delete/Change Request Form in the Registrar Relations area of our web site.

The following steps are required to process the IP Subnet changes:

  • Registrar determines the necessary add/delete/change to its IP Subnets.
  • Registrar verifies current IP Subnets and determines if the request meets the limits of the registry policy.
  • Via IP Subnet Form, registrar submits a request to add/delete/change IP Subnets. The request needs to include:
    • Registrar Name and ID
      • Name and security pass phrase of authorized Registrar contact
      • List current IP Subnets
      • List new IP Subnets
      • List IP Subnets to be deleted, if appropriate

Back to top

Q: What is a SSL Certificate?

A: 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 the registry's SRS.

Back to top

Q:Where do I get a SSL Certificate?

A: 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 Client Certificate CA Names
are:

  •  /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network
  • /O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
  • /O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa(c)00/CN=VeriSign Time Stamping Authority CA/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
  • /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa(c)05/CN=VeriSign Class 3 Secure Server CA
  • /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SSL Domain CA
  • /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
  • /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Server CA/emailAddress=server-certs@thawte.com
  • /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.com
  • /C=US/O=RSA Data Security, Inc./OU=Secure Server Certification Authority
  • /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
  • /C=US/O=VeriSign, Inc./OU=Class 2 Public Primary Certification Authority
  • /C=US/O=VeriSign, Inc./OU=Class 1 Public Primary Certification Authority
  • /C=US/O=VeriSign, Inc./OU=Class 4 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network
  • /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network
  • /C=US/O=VeriSign, Inc./OU=Class 2 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network
  • /C=US/O=VeriSign, Inc./OU=Class 1 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network
  • /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 1999 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 4 Public Primary Certification Authority - G3
  • /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 1999 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G3
  • /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 1999 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 2 Public Primary Certification Authority - G3
  • /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 1999 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 1 Public Primary Certification Authority - G3
  • /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
  • /C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
  • /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=EssentialSSL CA
  • /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO Certification Authority
  • /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
  • /C=US/O=Equifax Secure Inc./CN=Equifax Secure eBusiness CA-1
  • /C=US/O=Equifax Secure/OU=Equifax Secure eBusiness CA-2
  • /C=US/O=Equifax Secure Inc./CN=Equifax Secure Global eBusiness CA-1
  • /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2
  • /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
  • /C=US/O=GeoTrust Inc./CN=GeoTrust Universal CA 2
  • /C=US/O=GeoTrust Inc./CN=GeoTrust Universal CA
  • /C=US/O=Entrust.net/OU=www.entrust.net/CPS incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Secure Server Certification Authority
  • /C=US/O=Entrust, Inc./OU=www.entrust.net/CPS is incorporated by reference/OU=(c) 2006 Entrust, Inc./CN=Entrust Root Certification Authority
  • /C=US/O=Entrust, Inc./OU=www.entrust.net/CPS is incorporated by reference/OU=(c) 2006 Entrust, Inc./CN=Entrust Root Certification Authority
  • /C=US/O=Entrust, Inc./OU=AND ADDITIONAL TERMS GOVERNING USE AND RELIANCE/OU=CPS CONTAINS IMPORTANT LIMITATIONS OF WARRANTIES AND LIABILITY/OU=www.entrust.net/CPS is incorporated by reference/OU=(c) 2006 Entrust, Inc./CN=Entrust Certification Authority - L1A
  • /C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./OU=http://certificates.starfieldtech.com/repository/CN=Starfield Secure Certification Authority/serialNumber=10688435
  • /C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority
  • /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa(c)09/CN=VeriSign Class 3 Secure Server CA - G2
  • /C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA
  • /C=US/O=Thawte, Inc./OU=Domain Validated SSL/CN=Thawte DV SSL CA
  • /C=US/O=Thawte, Inc./CN=Thawte SSL CA
  • /C=US/O=Thawte, Inc./CN=Thawte Code Signing CA - G2
  • /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa(c)10/CN=VeriSign Class 3 Secure Server CA - G3
  • /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
  • /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority

 Back to top

Q: What is the requirement for the purpose of "SSL Client: Yes" for the SSL
certificate I purchase?

A: 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.

Back to top

Q: Which SSL toolkit should I use?

A: 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 (http://www.openssl.org/) is an open source SSL solution.

For Java:

Back to top

Q: Which cipher suites are accepted?

A: To establish a 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

Back to top

Q: When do I get the username/password for the production SRS?

A: The username and password for the production SRS is faxed after you have successfully completed OT&E certification and mTLD has approved your access to the production environment. That may require receipt of account funding, etc.

Back to top

Q: How do I change my www.mtld.mobi Registrar Relations area password?

A: There is one unique password per registrar, not per registrar contact. Should you need to change your password to comply with internal format or procedures, or due to turnover within your organization, you may contact operations@mtld.mobi to request a new Registrar Relations password. This does not affect your password or access to the EPP production system.

Back to top