An application that translates EPP over TCP connection into set of predefined HTTP calls.
Serves as direct replacement for mod_epp (https://github.com/mod-epp/mod-epp), and tries to emulate it's behaviour to the biggest possible extent.
Aside from the standard library of Erlang/OTP, it uses hackney for making HTTP requests and lager for logging.
We enforce the style from Erlang's own configuration. You can use the rebar3_fmt plugin to do it for you:
$ rebar3 fmt
The application listens on predefined TCP port for formatted EPP frames and translates them into HTTP requests according to the following matrix. Application performs regex search for clTRID and an XPATH search for command name. It does not check against any XSD schema.
EPP Command | HTTP request | Parameters | Headers | Payload Type | Cookies |
---|---|---|---|---|---|
hello | GET /epp_session_url/hello |
SSL-CLIENT-CERT, SSL-CLIENT-S-DN-CN, User-Agent, X-Forwarded-for | session | ||
login | POST /epp_session_url/login |
raw_frame, frame, clTRID |
SSL-CLIENT-CERT, SSL-CLIENT-S-DN-CN, User-Agent, X-Forwarded-for | form/multipart | session |
logout | POST /epp_session_url/logout |
raw_frame, frame, clTRID |
SSL-CLIENT-CERT, SSL-CLIENT-S-DN-CN, User-Agent, X-Forwarded-for | form/multipart | session |
poll | POST /epp_command_url/poll |
raw_frame, frame, clTRID |
SSL-CLIENT-CERT, SSL-CLIENT-S-DN-CN, User-Agent, X-Forwarded-for | form/multipart | session |
check | POST /epp_command_url/check |
raw_frame, frame, clTRID |
SSL-CLIENT-CERT, SSL-CLIENT-S-DN-CN, User-Agent, X-Forwarded-for | form/multipart | session |
info | POST /epp_command_url/info |
raw_frame, frame, clTRID |
SSL-CLIENT-CERT, SSL-CLIENT-S-DN-CN, User-Agent, X-Forwarded-for | form/multipart | session |
create | POST /epp_command_url/create |
raw_frame, frame, clTRID |
SSL-CLIENT-CERT, SSL-CLIENT-S-DN-CN, User-Agent, X-Forwarded-for | form/multipart | session |
delete | POST /epp_command_url/delete |
raw_frame, frame, clTRID |
SSL-CLIENT-CERT, SSL-CLIENT-S-DN-CN, User-Agent, X-Forwarded-for | form/multipart | session |
renew | POST /epp_command_url/renew |
raw_frame, frame, clTRID |
SSL-CLIENT-CERT, SSL-CLIENT-S-DN-CN, User-Agent, X-Forwarded-for | form/multipart | session |
update | POST /epp_command_url/update |
raw_frame, frame, clTRID |
SSL-CLIENT-CERT, SSL-CLIENT-S-DN-CN, User-Agent, X-Forwarded-for | form/multipart | session |
ANY (error) | GET /epp_error_url |
msg, code, clTRID |
SSL-CLIENT-CERT, SSL-CLIENT-S-DN-CN, User-Agent, X-Forwarded-for | query params | session |
Error route is used in case EPP frame is malformed.
The application performs TLS handshake, checks certficate against provided revocation list and acts as TLS termination proxy, passing on the certificate information downstream as HTTP headers. It also passes on the client IP address.
The application leverages OTP to isolate EPP clients from one another, each connection is owned by its own process. There are two processes that accept the connections and spin off workers, those are supervised in "one for one" strategy.
You need Erlang/OTP release 21 and Rebar3 to build it. No other versions than 21 were tested.
$ rebar3 compile
epp_proxy should be deployed as a self-contained Erlang application (release). You can create one with one of the following commands:
$ rebar3 release # Creates a release locally.
$ rebar3 tar # Creates an archive that can be shipped to another machine
$ rebar3 as prod release tar # Combines the steps above into single one, uses production profile.
The application is configured to automatically create releases based on git tags. After you develop a new functionality, you can create a release tag on Github.
You can then use appup to generate an upgrade path from currently running release to the new one. Assuming that a release currently running is v0.1.0, and you want to upgrade to v0.1.1, this is how the process looks like:
$ git checkout tags/v0.1.0 # Check out the older version.
$ rebar3 as prod release # Create the currently in use release, as it could have been deleted or corrupted in any way.
$ git checkout tags/v0.1.1
$ rebar3 as prod do release, appup generate --previous_version 0.1.0, relup, tar # Generate upgrade path, and then package it.
You can copy the archive with 0.1.1 to your target machine(s), and then execute:
$ ./bin/epp_proxy install 0.1.1 # Install the new version and marks it as permanent.
From there, you can either upgrade in place or restart into the new release.
$ ./bin/epp_proxy upgrade 0.1.1 # Upgrade in place.
$ ./bin/epp_proxy reboot # Reboot the VM completely into the new permanent release.
Configuration for the application tries to emulate the mod_epp configuration as close as possible
to make migration easier. The configuration is placed in config/sys.config
file, it takes a format
of Erlang property list.
Configuration variables
Variable name | Expected values | Apache equivalent | Definition |
---|---|---|---|
dev_mode |
true , false |
None | Enables TCP access without TLS. |
tls_port |
700 |
Listen | At which port should we open a TLS socket. Default is 700. |
tcp_port |
70000 |
Listen | At which port should we open a TCP socket. Only in dev_mode . |
epp_session_url |
https://example.com/epp/session |
EppSessionRoot | HTTP address of the session endpoints including schema and port. |
epp_command_url |
https://example.com/epp/command |
EppCommandRoot | HTTP address of the command endpoints including schema and port. |
epp_error_url |
https://example.com/epp/error |
EppErrorRoot | HTTP address of the error endpoints including schema and port. |
cacertfile_path |
/opt/ca/ca.crt.pem |
SSLCACertificateFile | Where is the client root CA located. Can be inside apps/epp_proxy/priv or absolute path. |
certfile_path |
/opt/ca/server.crt.pem |
SSLCertificateFile | Where is the server certificate located. Can be inside apps/epp_proxy/priv or absolute path. |
keyfile_path |
/opt/ca/server.key.pem |
SSLCertificateKeyFile | Where is the server key located. Can be inside apps/epp_proxy/priv or absolute path. |
crlfile_path |
/opt/ca/crl.pem |
SSLCARevocationFile | Where is the CRL file located. Can be inside apps/epp_proxy/priv or absolute path. When not set, not CRL check is performed. |
Checklist of steps to perform if you want to migrate from mod_epp, but still use Apache to be a reverse proxy.
- Remove SSL-CLIENT-S-DN-CN and SSL-CLIENT-CERT headers from Apache. Epp_proxy takes care of those.
- Install this project to desired location.
- Ensure that the user who will run epp_proxy has access to all certificate files.
- Set up syslog in
config/sys.config
. - If you do not feel comfortable using Erlang configuration file, you can use command line arguments and flags in format of
/epp_proxy/rel/bin/epp_proxy -epp_proxy tls_port 444
, where-epp_proxy
is name of application, followed by configuration parameter name and value.
The application comes with test suite written with common_test. For integration
tests, there is a small Roda application located in apps/epp_proxy/priv/test_backend_app
.
It has been written with Ruby 2.6.3.
There is also a number of generated ssl certificates that are used only for testing. Those are
valid until 2029 and they are located in apps/epp_proxy/priv/test_ca
. The password for test CA
is password
.
You need to start the backend application before running the test suite. To start it as a deamon, from the root folder of the project, execute:
$ /bin/bash -l -c "cd apps/epp_proxy/priv/test_backend_app && bundle install"
$ /bin/bash -l -c "cd apps/epp_proxy/priv/test_backend_app && bundle exec rackup --pid pidfile -D"
After you finish testing, you can stop the process by reading the stored pid:
$ kill `cat apps/epp_proxy/priv/test_backend_app/pidfile`
- Ensure CRL gets updated periodically without a need for restart of the service