CoCCA FAQ

From CoCCA Registry Services (NZ) Limited

Jump to: navigation, search

Contents

Why CoCCA

CoCCA is involved in the following activities:

  -  SRS Software Development and Deployment 
  -  Training and technical support  for ccTLD and gTLD
  -  Offsite backup, Data escrow and Disaster Recovery
  -  Maintenance of shared infrastructure

DB house keeping


In most Cases the Registry Administrator enable WHOIS, EPP logging which make the Registry Database growth, for this CoCCA Registry System after on the newer patches v8.1.20150308, added the Cleanup Auditing feature, you can enable this feature if want the registry to clean up the auditing tables automatically


you can enable this feature from Registry GUI ------>Configuration ------>in Right side you will find "Site" config, then you will get the same following screen:



Start important services in Registry OS

- Important to check if all important services will start after reboot:

Execute the following command to see the enabled services after reboot OS:
1- chkconfig --list | grep $(runlevel | awk '{ print $2}'):on
for example we will see like this output:
   $sudo chkconfig --list | grep $(runlevel | awk '{ print $2}'):on
    cocca           0:off   1:off   2:on    3:on    4:on    5:on    6:off
    fail2ban        0:off   1:off   2:on    3:on    4:on    5:on    6:off
    ip6tables       0:off   1:off   2:on    3:on    4:on    5:on    6:off
    iptables        0:off   1:off   2:on    3:on    4:on    5:on    6:off
    named           0:off   1:off   2:on    3:on    4:on    5:on    6:off
    ntpd            0:off   1:off   2:on    3:on    4:on    5:on    6:off
    rsyslog         0:off   1:off   2:on    3:on    4:on    5:on    6:off
    sshd            0:off   1:off   2:on    3:on    4:on    5:on    6:off

The first column of above output is the name of a service which is currently enabled at boot. the Most important level in production systems is runlevel 3. i above out put we will see the important services in Registry system which should be enabled at reboot time:

1- cocca script: this script will start cocca Registry SRS after reboot your system.
2- fail2ban:  this script will start fail2ban software to prevent the ssh and other services DOS attack.
3- iptables, ip6tables:  this script will start iptables and ip6tables, for this you should configured the iptables in with right rules.
4- ntp :  this script will start ntp service, which it important for google-authintictor to sync with google servers.
5- named: this script will start named service.
- for exampele To enable named service in centos, enter:
  $ sudo chkconfig named on
- for exampele To disable ip6tables service, enter:
  $ sudo chkconfig ip6tables off

In CentOS 7 we can manage services through systemctl, the systemd service manager.

Execute the following command to see the enabled services after reboot OS:
 $ sudo  systemctl list-unit-files -t service  |grep enabled

fail2ban.service enabled

ntpd.service enabled

rsyslog.service enabled

sshd.service enabled


To check if a single service starts on boot, run the systemctl status command on your service and check for the "Loaded" line.

$ systemctl status named

To enable service in centos 7

$ systemctl enable named

How to Import Domains to CoCCA


you can use CSV file to import domains info from old Registry software to CoCCA Registry Software, the Overview of the import process as the following:


1 Create the TLD and zones  .TLD / com.TLD /org.TLD etc 

2 It is advisable to import all the domains into a single "migration registrar", this is a normal registrar setup for the purpose.  After you 
  have imported the data then you can create other registrars and "push" lists of the domains to the "proper" account.

For the migration registrar you can set the price to "0" for all the zones and give credit of "1" dollar.


You can import from GUI ---> Domains ---> in Right side you will find "import Domains".


3 Importing requires multiple tries, the import is "all or nothing", the import validation will display errors in the UI then you fix the  
  errors in the CSV, save a new file and try again until it works. 

Notes 1:

    emails can only have one email not two separated by "/" etc. 

Notes 2:

     If you dont have data for some clients you can create a single "migration contact" in the UI fist and map the domain to it in the CSV.  In 
     this case you add the "ID" column and then leave the contact records empty. 

The CSV format:


CSV file is a TSV (tab separated) text FILE. The first row of the file is assumed to be headers and will be ignored. The remainder of the rows will be imported one at a time. If any errors are encountered the domain will not be imported and a message will be supplied. The file must --- have the following columns:


   Column 1	Domain Name	The full name of the domain. Ensure you have access to the zone and sufficent credit.
   Column 2	REGISTRANT ID	The contact ID of the REGISTRANT.
   Columns 3,4,5,6,7,8	   Name Servers	 Optional name servers. Host records for these name servers must exist for the import to be successful.
   Column 9	Admin Contact ID	Optional administrative contact, the id must already exist.
   Column 10	Tech Contact ID	Optional technical contact, the id must already exist.
   Column 11	Billing Contact ID	Optional billing contact, the id must already exist.

File:Sample.csv


How to Add new Zone


CoCCA Registry system allow the Registry administrator to add new zone easily then the new zone will included in next zone file generation, the whole process of add new zone should be as the following:


 1- add new zone from CoCCA Registry Software GUI ----> Zones --->in Right side Create Zone:

    

 2- add right zone header including SOA, the authoritative name server, .., then you should enable publish the zone, you can config those  
    parameters from Registry GUI ----> Zones---->choice newly created zone "com.TLD" ----> in Right side you will find Zone file settings,
    as the following picture:

     

 3- if the new zone is sub zone like com.TLD you should register the zone under .TLD and add the same name server at the zone header, 
    in our example it:
    ns1.nic.TLD.xxx.
    ns2.nic.TLD.xxx.
    ns3.nic.TLD.xxx.
    ns4.nic.TLD.xxx.

 4- config bind in your Hidden master server to allow Axfer / Notify the secondary DNS providers of the new zone.

 5- contact all the secondary providers and ask them to also pull the new zone.

Generate EPP SSL Certificate using java keystore

To generate new certificate and load it, got tired of the SSL error and the old CoCCA cert. we can here explain the Procedure:


CoCCA uses java keystore files for the SSL, the certificate is needed for the web portal and for EPP.

Step 1


Create keystore and cenerate the CSR to send to certificate authority.

The program to create and manage certs is the java keytool it lives in /opt/cocca-8/java/bin We create the keystore and CSR with the following command:(example generate Certificate for .OTE CoCCA)


./keytool -genkey -alias server -keyalg RSA -keysize 2048 -keystore registry_cocca_ote.jks -dname "CN=registry.cocca.ote,OU=Naming and Numbering, O=CoCCA Registry Systems , L=Aculand, ST=Aculand, C=NZ" && ./keytool -certreq -alias server -file registry_cocca_ote.csr -keystore registry_cocca_ote.jks


( create password when prompted - it prompts for 2, use the same for both.. )


Step 2


send the CSR file away for signing, example digicert


Step 3


When the authority sends you files back import the intermediate certificate and the singed certificate for your domain as :


./keytool -import -trustcacerts -alias intermediate -file DigiCertCA.crt -keystore registry_cocca_ote.jks ( enter password )


./keytool -import -trustcacerts -alias server -file registry_cocca_ote.crt -keystore registry_cocca.ote.jks


( enter password ) Copy the keystore to /opt/cocca-8/keys


Step 4


Edit the webserver ( resin ) to point to the new keystore


 /opt/cocca-8/resin/conf/resin.xml  

look for this section ... <http address="xxx.xxx.xxx.xxx" port="443">

         <jsse-ssl>
             <key-store-type>jks</key-store-type>
             <key-store-file>/opt/cocca-8/keys/registry_cocca.ote.jks</key-store-file>
             <password>******</password>
             <protocol>TLSv1,TLSv1.1,TLSv1.2</protocol>
         </jsse-ssl>
       </http>


Stop and Start resin /opt/cocca-8/ctlscript.sh stop resin / start


Step 5


Edit the EPP certificate settings in the CoCCA UI.


Config > EPP


Enter the path and password as appropriate, As the following figure:File:ConfigureEPP.jpg


How to secure EPP using two way certificate authentication


CoCCA Registry Software support EPP over TLS by default, and the connection must be encrypted to be parsed and the EPP client be able to send EPP command, at same time CoCCA try to simple the EPP over TLS as possible, for this the CoCCA offer multi option to allow EPP client connect to Registry over TLS:

- First: 
  The CoCCA Registry Software allow EPP client to establish EPP over TLS connection without provide client certificate, this is the easy approach, but the connection 
  must be EPP/TLS.

- Second: 
  The CoCCA Registry Software allow EPP client to establish EPP over TLS connection with it's certificate, the certificate format should be .pem, we will see how to 
  genereate the .pem certificate using famous tools like openssl.

- Third:  
  The CoCCA Registry Software require clients to use Registry-managed SSL Certificates to connect via EPP, this mean the client certificate is trusted by the SRS    
  keystore, and the SRS force the EPP client to establish EPP over TLS connection and the certificate should be signed by Registry certificate, and this required 
  number of steps to complete the proccess, as the next section will explain that "use Registry-managed SSL Certificates".

use Registry-managed SSL Certificates

the important thing is to implement the two way of certificate authentication between the client and server, and we should choice the option from Registry UI: use any certificate signed by Registry Certificate which will generate when active Require EPP Client Certificates, as the following figure show:



The idea is very simple, CoCCA Registry system will create new Signing certificate, then this certificate will sign all Registrar EPP certificate,

The basic steps

- using Registry UI add new CoCCA signing certificate (as previous figure), this certificate will be used as CA certificate, then will be stored at server jks  in 
 previous figure we name it: epp_trust_ca.jks (it will be diffrent than EPP JKS in Registry EPP config).
- add CoCCA CA certificate to catrust store in JAVA. 
- use the client EPP jks which also generated by Registry UI to generate EPP client csr for each registry (you will find it at same path of JKS server in figure  
 the path will be "/opt/cert/epp_trust_ca.jks-client" .
- Generate then Sigin every EPP registrar csr by the CoCCA CA key and Certificate (after extrcat it from /opt/cert/epp_trust_ca.jks JKS), then you will get the EPP    
 client certificate.
- append the signed csr (client certificate) with the EPP client private key (which will extracted from jks) as one file.
- send it to your EPP Registrar to use it, you can use it in WHMCS with CoCCAEpp module, pdtepp-test and other EPP clients, ... .

The detailed steps


1 - Export eppsigningroot certificate to be trust CA :

   $ /opt/cocca-8/java/bin/keytool -export -alias eppsigningroot -file coccaCA.cer -keystore epp_trust_ca.jks

2- Import New CoCCA CA certificate in cacerts jks in java:

  $ /opt/cocca-8/java/bin/keytool -importcert -file coccaCA.cer -keystore /opt/cocca-8/java/jre/lib/security/cacerts -alias coccaCA -keypass changeit

3- Generate the Certificate Signing Request for EPP clients:

  $ /opt/cocca-8/java/bin/keytool -certreq -alias epplocalcert -keystore epp_trust_ca.jks-client -file eppclient.csr

4- extract The CoCCA CA cert (der format ) and private key from keystore to sign the EPP client CSR:


 a- extract private key, then convert it to .pem format:
    $/opt/cocca-8/java/bin/keytool -importkeystore -srckeystore epp_trust_ca.jks -destkeystore KEYSTORE.p12 -srcstoretype JKS -deststoretype PKCS12 -srcstorepass  
    changeit -srcalias eppsigningroot -destalias eppsigningroot

    $openssl pkcs12 -in KEYSTORE.p12 -out Key.pem -nodes -nocerts

 b- convert the certificate type from der format to .pem format to sign the EPP client csr latter.
    $openssl x509 -inform der -in coccaCA.cer -out coccaCA.pem  (can add -nokey option)

5- import the CoCCA CA certificate into client epp jks to avoid " no certificate chain ":

  $ /opt/cocca-8/java/bin/keytool -import -keystore epp_trust_ca.jks-client -file coccaCA.cer  -alias eppCARoot

6- Sign EPP client certificate with CoCCA CA:


  $ openssl x509 -req -days 365 -in eppclient.csr -CA coccaCA.pem -CAkey Key.pem -CAcreateserial -out eppclient.cert -days 365  -CAcreateserial

7- the EPP client certificate is ready now, we need the .pem format for this we should extract the private key from the client EPP keystore:

  $ /opt/cocca-8/java/bin/keytool -importkeystore -srckeystore epp_trust_ca.jks-client -destkeystore KEYSTOREclient.p12 -srcstoretype JKS -deststoretype PKCS12    
    -srcstorepass changeit -srcalias epplocalcert -destalias epplocalcert

  - then convert it to .pem format:
    $ openssl pkcs12 -in KEYSTOREclient.p12 -out Keyclient.pem -nodes -nocerts

8- test your work before send this new EPP client to Registrar using openssl command line with debuging option:

  $ openssl s_client -connect epp.registry.nic.TLD:700  -cert eppclient.cert -key Keyclient.pem -state -quiet

9- for EPP clients as WHMCS CoCCA EPP module and pdtepp client we should use the .pem format for this we can append the key to certificate in one file with the

  extension : .pem then we can test as the following:

  $ cat  eppclient.cert >>EPP_Client_cert.pem
  $ cat  Keyclient.pem  >>EPP_Client_cert.pem

10- Test the .pem certificate :

   $ openssl s_client -connect ote.coccaregistry.org:700  -cert EPP_Client_cert.pem  -state -quiet

Warning from browser: your connection is encrypted using an obsolete cipher suite What This mean ?


Maybe you get this warning at your browser your connection is encrypted using an obsolete cipher suite as the following figure:


200x


but What This mean and how i can resolve it in CoCCA Registry system, we know the CoCCA use the resin as web server, and the resin according to java version support number of cipher suites, you can see the cipher suite which your current java version support via vist the Oracel site, for example to see what the cipher suite supported by JAVA 1.8 (JDK 8u60 or greater) you can check this link Cipher Suites, but some of those cipher suite listed as obsolete cipher suite, for this you can choices the sutabile cipher suite according to your JAVA version, and your certificate type, these is a recommended cipher suites by NIST see Table 3-3 TLS 1.2 Cipher Suites for RSA Server Certificates.

How i can change the cipher suites in resin

resin configuration file resin.xml can force browser and resin to use higher security connection by determine the supported cipher suite, if you look at the resin.xml file you will find the following line for example:


   <cipher-suites>TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA</cipher-suites>

This line force the resin to use the three ciphers: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA The Cipher suites have the form: TLS_KeyExchangeAlg_WITH_EncryptionAlg_MessageAuthenticationAlg. For example, the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA uses RSA for the key exchange, AES-128 in cipher block chaining mode for encryption, and message authentication is performed using HMAC_SHA.


what is recommended cipher suite and how i can remove obsolete Warning

To remove the obsolete Warning , you should get the modern cryptography which is defined as:

 - TLS 1.2 as protocol
 - AES_128_GCM as cipher
 - DHE_RSA or ECDHE_RSA or ECDHE_ECDSA as key exchange.

and the recommended cipher suite line in resin.xml file is:


 <cipher-suites>    
TLS_DH_anon_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
 </cipher-suites>

IDN support in CoCCA

CoCCA Registry system fully supporting Internationalized Domain Names (“IDNs”), and compliance with the requirements of the IETF protocol for Internationalized Domain Names based on Unicode 6.2 and IDNA2008, and supports the concept of variants using simple and elegant solution.

variants in CoCCA

When dealing with IDN domains with variants, the CoCCA Registry applies the folding rules to find the canonical domain. This domain has all variants replaced with the index characters from the appropriate variant rules. This domain is stored in the database, and forms the master record for the name. When operations are run on the registry such as EPP queries or WHOIS, the variant rules are applied to the operation to find the canonical domain name. The relevant operation is then applied to the matching canonical name. This means that the same information is provided for all queries on a name, and any update on a name or its variants, is applied to the master record. There are no variant domain records maintained in the registry. By way of example, the EPP and WHOIS servers when responding to a query or update request for “domain1.tld” will apply the folding rules to the query and perform the action on the master record, “domain.tld” – in instances where domain1.tld is variant of domain.tld. Once the canonical version of a name has been registered, any further variants will not be able to be registered. After applying the folding rules, the EPP server will see that the master record exists and interprets the request as an attempt to register an already registered domain. When generating zone files, or displaying the name in the UI the folds are applied to the index (canonical) name to expand the name into all possible variants.

Compliance with ICANN requirements

- Registration of variants of the same index variant of a name are prohibited. Since each variant is changed to its index form before registration, it is impossible to register two variants of a name separately. - The CoCCA methodology is “By default variant IDNs (as defined in the Registry Operators IDN tables and IDN Registration Rules) must be blocked from registration.

- Activation. On zone generation, if the registrar has requested that variants be included in the zone (via their login at the registry portal), all variations of a domain name will be expanded (using the information in the master record) and included in the zone file. Activation is a registrar preference that can be toggled in the registry portal.

- The CoCCA methodology also include “Variant IDNs may be activated when requested by the sponsoring Registrar of the canonical name as described in the IDN Tables and IDN Registration Rules”

- Each variant of the name is simply a reference to the canonical version, so any query on a variant will return the same information as for the index version.

- The NS resource records for variants in the zone the will always have the same records as the canonical version.

CoCCA and Pre-Delegation Testing

recently The CoCCA Registry system passed the Pre-Delegation Testing for the ICANN's New gTLD program for number of gTLD, including the همراه. IDN. and help to put the CoCCA Arabic IDN Tables and Rules for IDN and implement the folding rules for a number of IDN ccTLD.

How to make your own receipts reports design

You can make your changes on the default pdf format for transaction receipts in CoCCA, CoCCA uses jasper to generate reports and save it as pdf, CoCCA use a default theme for all transaction receipts, like Pro-forma invoices template and use CoCCA logo as background and uses some default colors and lines on top, it is easy to create your own reports.

How I can start my changes

The first step: knowing where CoCCA store the .jasper templates, CoCCA store all transaction receipts templates in your CoCCA installation path, by default it will be into : /opt/cocca-8/production/ROOT/ireports/ And the default templates are:

       abstract-receipt-A4.jasper
       payment_transaction-LETTER.jasper 
       abstract-receipt-LETTER.jasper 
       pro-forma-invoice-A4.jasper
       payment_transaction-A4.jasper
       pro-forma-invoice-A4_tld_totals.jasper

The second step:

Begining edit themes and use your report design, the .jasper file type is a Java class file and you can use Jaspersoft report design tools to convert the files back to report template in XML format, so you can make your changes and compile the XML files and generate the .jasper files again and use them, so you can start with downloading TIBCO Jaspersoft Studio-6.4.0, then edit the default templates, for example we can start with pro-forma-invoice-A4.jasper, start with opening the pro-forma-invoice-A4.jasper file:



You can make your changes on subject and site name, also you can change the background logo, the default background logo image is startbg.png, and you can find it in the following path: /opt/cocca-8/production/ROOT/images/ example changes:



So you can change it in the XML file or use your own logo with the same name, and after your changes just save changes and compile the XML file then you will get new .jasper file:



The final step is moving this new .jasper file to your registry path and remove the old .jasper file, so your registry will use it.

Personal tools