I2P_Developers/i2p.www
3
0
Fork 5
Code Issues 27 Pull Requests Actions 1 Packages Projects Releases Wiki Activity

Compare commits

merge into: I2P_Developers:master
Branches Tags
I2P_Developers:master I2P_Developers:166-identity-aware-proxies I2P_Developers:modernize I2P_Developers:2to3 I2P_Developers:debian-variants-questionable I2P_Developers:reseed-rewrite I2P_Developers:reseed-revisions I2P_Developers:debchanges I2P_Developers:dns-application I2P_Developers:download-pages-breakdown-redirect I2P_Developers:dmg-bundle-expanded I2P_Developers:style-guide
I2P_Developers:cvs-suck-import
...
pull from: I2P_Developers:reseed-revisions
Branches Tags
I2P_Developers:master I2P_Developers:166-identity-aware-proxies I2P_Developers:modernize I2P_Developers:2to3 I2P_Developers:debian-variants-questionable I2P_Developers:reseed-rewrite I2P_Developers:reseed-revisions I2P_Developers:debchanges I2P_Developers:dns-application I2P_Developers:download-pages-breakdown-redirect I2P_Developers:dmg-bundle-expanded I2P_Developers:style-guide
I2P_Developers:cvs-suck-import

1 Commits
master ... reseed-rev

Author SHA1 Message Date
idk
036173e6bc Start trimming down the overly-elaborate and/or redundant reseed instructions 2021-11-20 21:31:45 -05:00
3 changed files with 62 additions and 622 deletions
Expand all files Collapse all files

19
README.md
View File

@ -46,11 +46,20 @@ If you want to mirror the I2P website, thanks! Here is a checklist:
It's possible to set up a mirror using apache2 inside of a Docker container.
It is intended to provide a HTTP server, to use HTTPS, using a reverse proxy
is the easiest way. You should not need to make any modifications to the
service running inside the container, but you may make the same modifications
to the containerized mirror that you would to a normal mirror by changing your
local copy of the site according to the recommendations in the previous
settings.
is the easiest way.
- The `site-updater-docker.sh` is configured to pull from the `git remote` which
you are tracking, usually `origin`. If you cloned from a client tunnel, such
as `git@127.0.0.1:i2p-hackers/i2p.www` using the `git-ssh` tunnel on 7670, then
that is where you will `pull` new updates in from, as well. Therefore,
`etc/update.vars` is unnecessary/unused.
- Caching using `i2pwww/settings.py` works normally by copying `i2p2www/settings.py.sample`
to `i2p2www/settings.py` and editing *before* building the image.
- It is possible to set the variables: `i2p_www_docker_build_args`,
`i2p_www_branch`, `suffix`, `port` to configure how the image and container
are built. See the top of `site-updater-docker.sh` for details.
- To automatically start an HTTP mirror on port 8090, run: `site-updater-docker.sh`

6
i2p2www/pages/site/docs/reseed.html
View File

@ -34,8 +34,14 @@ prevent users of I2P from connecting to the network.
<ul>
<li><a href="{{ site_url('get-involved/guides/reseed') }}">Reseed Contributors Guide</a></li>
<li><a href="https://i2pgit.org/idk/reseed-tools">Reseed Software and Documentation</a></li>
<li><a href="/en/docs/spec/updates">SU3 Reseed File Format Specification</a></li>
<li><a href="http://zzz.i2p/topics/1893">zzz.i2p thread</a></li>
<li><a href="http://zzz.i2p/topics/1716">zzz.i2p thread</a></li>
</ul>
{% trans -%} If you have questions about reseeding, please ask them on the reseed forum of {%- endtrans %}
<a href="http://zzz.i2p/forums/18">zzz.i2p</a>.
<h2 id="other">{% trans %}Other ways of Reseeding{% endtrans %}</h2>
<p>

659
i2p2www/pages/site/get-involved/guides/reseed.html
View File

@ -79,6 +79,7 @@ If you would like to discuss support, please contact echelon and CC: zzz
<p>{% trans -%}
Our reseed coordinator is "zzz" and he may be contacted at zzz at mail.i2p or zzz at i2pmail.org.
Unfortunately, he is not generally on IRC. The reseed setup is somewhat specialized, and you should direct most questions to him.
IDK is able to answer questions about the reseed software.
{%- endtrans %}</p>
<p>{% trans -%}
@ -89,7 +90,6 @@ For actual implementation, details below. We have one recommended reseed solutio
<li>{% trans -%}
A Go implementation that includes the web server and all the scripts. This is the recommended solution.
{%- endtrans %}</li>
</ul>
<p>{% trans -%}
@ -97,14 +97,9 @@ For further information, read the information at the following links, and then c
Thank you!
{%- endtrans %}</p>
<ul><li>
<a href="http://zzz.i2p/topics/1893">zzz.i2p thread</a>
</li><li>
<a href="http://zzz.i2p/topics/1716">zzz.i2p thread</a>
</li><li>
<a href="https://github.com/martin61/i2p-tools">Go reseed server source on github</a>
</li><li>
<a href="/en/docs/spec/updates">SU3 Reseed File Format Specification</a>
<ul>
<li><a href="https://i2pgit.org/idk/reseed-tools">Go reseed server source on gitlab</a></li>
<li><a href="https://github.com/eyedeekay/i2p-tools-1">Go reseed server source on github</a></li>
</li></ul>
<h2>{% trans %}Detailed Instructions{% endtrans %}</h2>
@ -112,87 +107,71 @@ Thank you!
<h3>How-to Public reseed servers - su3</h3>
<ul>
<li>Some parts of this how-to are copied from <a href="http://zzz.i2p">zzz.i2p</a> and are modified.
<li>Fetching individual RI (dat-files -the legacy/old style-) is not part of this how-to.
<li>Questions can be placed on <a href="http://zzz.i2p/forums/18">zzz.i2p</a> - in the Reseeding sub-forum.
<li>Some parts of this how-to are copied from <a href="http://zzz.i2p">zzz.i2p</a> and are modified.</li>
<li>Fetching individual RI (dat-files -the legacy/old style-) is not part of this how-to.</li>
</ul>
<h3>Table of contents</h3>
<ol>
<li>Introduction
<li>Requirements
<li>Go Solution - Quick Guide
<li>Introduction</li>
<li>Requirements</li>
<li>Go Solution - Quick Guide</li>
<ol>
<li>Start Web Server
<li>Install git and golang
<li>Build and Test
<li>Run Reseed
<li>Backup Certificates and Keys
<li>Enable Autostart
<li>Connect Web Server to Reseed
<li>Test From Another Computer
<li>Send Us Your Certificates
<li>Run Reseed</li>
<li>Backup Certificates and Keys</li>
<li>Enable Autostart</li>
<li>Connect Web Server to Reseed</li>
<li>Test From Another Computer</li>
<li>Send Us Your Certificates</li>
</ol>
<li>Go Solution -Detailed Guide
<ol>
<li>Overview
<li>Building From Source
<li>Run The Reseed Server
<li>Draft For Startup Script
<li>Reverse-Proxy Setup
<li>Convert Existing Java Keystore to crt- and pem-file
</ol>
<li>Seamless SSL-Certificate Exchange
<li>Reseed Server Domain/URL/Port Exchange
<li>Tests
<li>Contact Reseed Maintainer
<li>Seamless SSL-Certificate Exchange</li>
<li>Reseed Server Domain/URL/Port Exchange</li>
<li>Tests</li>
<li>Contact Reseed Maintainer</li>
</ol>
<h2>1. Introduction</h2>
<p>
Public reseed servers are necessary to bootstrap into the I2P net.
New installed I2P routers needs one-time about one hundred RouterInfo's (RI) as jump start.
</p>
<p>
RI contains IP and Port from other I2P routers and are stored in dat-files in the netDB folder.
</p>
<p>
A random bunch of dat-files from the netDB are zipped, then signed to a su3-file
and finally offered to I2P routers seeking reseed service.
Public reseed servers are necessary to bootstrap into the Invisible Internet.
Newly installed I2P routers use reseed server to download between 75 and 100 "routerInfos"
which contain peer information which you use to make your first connections. Reseed servers
carefully distribute a subset of the routerInfos available to them in order to help new routers
join the network.
</p>
<p>
To secure bootstrap and enable a trusted start, HTTPS/TLS and signed su3-files are mandatory.
The reseed server software deals with this automatically, or you may disable the reseed's
built-in HTTPS server in favor of a reverse proxy to provide HTTPS. NGINX is a popular choice.
</p>
<p>
It is essential not to publish all RI from netDB, or all RI to one client.
</p>
<h2>2. Requirements</h2>
<p>
Requirements for running a public reseed server:
<ul>
<li>Well integrated running I2P router @ 24/7
<li>Server with static IPv4 (2 cpu/ 2GB ram is fine)
<li>Unix to run the golang solution
<li>Own domain, sub-domain or an anonymous third-level domain
<li>A self-signed SSL certificate, or an SSL certificate from <a href="https://letsencrypt.org" target="_blank">Let's Encrypt</a>
<li>Enough bandwidth and traffic volume - Around 15 GB/month as of December 2016
<li>Up-to-date web server (Apache/nginx), HTTPS ONLY with TLS 1.2 and good ciphers
<li>Well integrated running I2P router @ 24/7</li>
<li>Server with static IPv4 (2 cpu/ 2GB ram is fine)</li>
<li>Own domain, sub-domain or an anonymous third-level domain. Alternatively, some reseed servers may operate as `.onion` sites, however
visible internet domains are preferred.</li>
<li>A self-signed SSL certificate, or an SSL certificate from <a href="https://letsencrypt.org" target="_blank">Let's Encrypt</a></li>
<li>Enough bandwidth and traffic volume - Around 15 GB/month as of December 2016</li>
</ul>
Optional:
<ul>
<li>fail2ban to protect you from botnets
<li>GnuPG/PGP for signed/encrypted emails
<li>IPv6
<li>fail2ban to protect you from botnets</li>
<li>GnuPG/PGP for signed/encrypted emails</li>
<li>IPv6</li>
<li>Up-to-date web server or reverse proxy (Apache/nginx), HTTPS ONLY with TLS 1.2 and good ciphers</li>
<li>Tor(for `.onion` reseeds only)</li>
</ul>
<p>
This How-to is tested with Ubuntu/Debian as well as FreeBSD.
The web server has to be public reachable from all over the world, an I2P Site inside I2P can be setup in addition.
Also frequent or infrequent attempts to scrape all your reseed files, and of course attacks on your server.
This How-to is tested with Ubuntu/Debian as well as FreeBSD, but should work on any Linux, BSD, OSX, or Windows system.
</p>
<p>
The web server has to be public reachable from all over the world, unless the reseeed is intended to be `.onion` only.
Your server should be kept up-to-date and appropriately hardened against attacks using fail2ban, apparmor, IPTables, etc.
The web server doesn't need to listen at default SSL/TLS port 443 - any other port can be used for obfuscation.
</p>
@ -323,469 +302,6 @@ Note: i2p-tool has also an build-in standalone webserver with TLS support which
<p>
Send an email: zzz at mail.i2p, PGP signed welcome :-)
<h2>4. Go Solution - Detailed Instructions</h2>
<h3>1. Overview</h3>
<p>
The previous steps for reseeding involves many steps, scripts and programs.
Most of them are easy and plain straight forward, but overall you can call it a little confusing.
<p>
Here comes now an all-in-one solution from matt (Big Thanks!) for providing
a reseed server which merges the following functions into one binary:
<ul>
<li>Create su3-files
<li>Create su3 signer certificate+key
<li>Create SSL-certificate+key
<li>Replaces the http-server and the PHP code (or run next to them in parallel)
</ul>
<p>
Almost all previous used scripts and described steps are not needed with this solution,
but to understand the overall reseed process it is recommended to read them too :-)
<ul>
<li>If you already have an SSL-certificate and su3-signer-key you can reuse them, see one of the following chapter.
<li>For testing and new reseeders the required certs and keys are created automatically at first start.
<li>Also take a look at the content and the naming scheme of these pem and crt files.
</ul>
<p>
Of course you need an up-to-date netDB folder with routerinfos from a running I2P router.
I2P does not have to be running on the same machine as this reseed binary.
In this case you can setup a cronjob to transfer the netDB from the I2P machine to the reseed machine.
<p>
Matt's go solution can be used in parallel next to an already running http-server.
For this leave the http-server running at normal port 80 and 443,
and configure Go solution too use another port, e.g. port 8443.
<p>
More: at github, README.md, https://github.com/martin61/i2p-tools
<h3>2. Building From Source</h3>
<p>
Requirements:
<ul>
<li>go1.4.2 (older versions may not work)
</ul>
<p>
Install go from https://golang.org/doc/install, example for 64 bit Ubuntu/Debian:
<ul>
<li>wget https://storage.googleapis.com/golang/go1.4.2.linux-amd64.tar.gz
<li>sudo tar -C /usr/local -xzf go1.4.2.linux-amd64.tar.gz
<li>mkdir $HOME/go
<li>edit /etc/profile and add:
<pre>
export GOPATH=$HOME/go
export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin
</pre>
</ul>
<p>
Verify go:
<pre>
$ go version
</pre>
which should state something like: "go version go1.4.2"
<p>
Install Go solution from https://github.com/martin61/i2p-tools into $HOME/go:
<pre>
$ go get github.com/martin61/i2p-tools
</pre>
<p>
This will install a binary to $GOPATH/bin/i2p-tools
<p>
Run the go solution, the usage/help should be displayed, nothing more:
<pre>
$ i2p-tools
</pre>
<h3>3. Run the Reseed Server</h3>
<pre>
$ i2p-tools reseed --tlsHost=myserver.com --signer=myemail@mail.i2p --netdb=$HOME/.i2p/netDb
</pre>
<ul>
<li>Replace myserver.com with your real domain
<li>Replace myemail@mail.i2p with a valid existing email, which you want to use for reseeding purpose
<li>New TLS certificate+key will be created (if they do not exist)
<li>New signing certificate+key will be created (if they do not exist)
<li>netdb=... should point to the netdb folder of your running I2P with the routerinfos
<li>To use another port append "--port=443" to the command, default is port 8443
</ul>
<p>
Output:
<pre>
2015/03/15 12:28:25 Rebuilding su3 cache...
2015/03/15 12:28:25 Building 200 su3 files each containing 75 out of 3180 routerInfos.
2015/03/15 12:28:35 Done rebuilding.
2015/03/15 12:28:35 HTTPS server started on 0.0.0.0:8443
</pre>
<p>
So you can now test to reach the server at port 8443, see a previous chapter about proper testing.
<p>
Some remarks:
<ul>
<li>Don't run the server daemon as root
<li>Every port between 1024 and 49151 is fine for I2P.
<li>If you want to use the privileged (https-default) port 443, create a port redirect, e.g.
<pre>'iptables -A PREROUTING -t nat -p tcp --dport 443 -j REDIRECT --to-port 8443'</pre>
<li>Redirect the output from the go solution to a logfile, format is default apache-style combined logs
<li>Add a logrotate for the logfiles, since they grow big :-(
<li>Logfiles can be used by fail2ban
<li>Both of the certificates (*.crt) will need to be sent to the reseed maintainer
in order for your reseed server to be included in the standard I2P package.
<li>Add a proper startup script, to run the reseed server, see next chapter
</ul>
<h3>4. Draft for Startup Script "seedserver"</h3>
<p>
The reseed server should be started automatically, so you need a init.d or some sort of
startscript, here named as "seedserver".
This is only a very first draft for a simple startscript (it could be done better :-))
<p>
Login as I2P user:
<ul>
<li>Place the shell-script "seedserver" in the /home/i2p/bin folder (next to i2p-tools)
<li>Make it executable: chmod u+x /home/i2p/bin/seedserver
</ul>
Update the header "# Your settings" with your individual settings.
<p>
Now you can use the shell-script:
<pre>
seedserver start
</pre>
<p>
And then (give it some seconds) take a look at the status:
<pre>
seedserver status
seedserver showlog
</pre>
<p>
Some short explanation about seedserver:
<ul>
<li>runs i2p-tools in the background
<li>creates logfiles
<li>take care of all settings
</ul>
<p>
If this is working fine, you can put the script in your personal crontab, to run it by auto-start
and to do logrotes simply by restarting it regularly once a week to avoid too big logfiles.
If you already reboot your server regularly, you can skip of course the "restart" command line.
<p>
Login as I2P user, edit your crontab:
<pre>
crontab -e
</pre>
<p>
and add these 3 lines at the end:
<pre>
@reboot /home/i2p/bin/seedserver startdelayed
04 14 * * 2 /home/i2p/bin/seedserver restart
#end
</pre>
<p>
Save and close the editor. It would be good to check if this is properly working when you reboot your machine.
<p>
"seedserver" shell script:
<pre>
######################################################################################################
#!/bin/sh
# Your settings
toolpath=/home/i2p/bin
tlsHost=myserver.com
signer=myemail@mail.i2p
netdb="/home/i2p/.i2p/netDb"
tool=i2p-tools
logpath="$toolpath/${tool}.log"
logfile="$logpath/reseed.log"
errfile="$logpath/reseed.error"
cd "$toolpath"
mkdir --parents "$logpath"
do_status() {
/bin/sleep 1
if [ -n "$(pgrep -x "$tool")" ]; then
echo "$tool running, pid $(pgrep "$tool")"
else
echo "$tool not running."
fi;
}
do_start() {
if [ -z "$(pgrep -x "$tool")" ]; then
do_logrotate
nohup "$toolpath/$tool" reseed -tlsHost="$tlsHost" --signer="$signer" --netdb="$netdb" &gt; "$logfile" 2&gt; "$errfile" &
fi;
do_status
}
do_stop() {
if [ -n "$(pgrep -x "$tool")" ]; then
pkill "$tool"
fi;
do_status
}
do_startdelayed() {
echo "waiting 20s..."
/bin/sleep 20
do_start
}
do_restart() {
do_status
do_stop
do_start
}
do_logrotate() {
do_status
if [ -z "$(pgrep -x "$tool")" ]; then
mv --force "${logfile}.6" "${logfile}.7" 2&gt;/dev/null
mv --force "${logfile}.5" "${logfile}.6" 2&gt;/dev/null
mv --force "${logfile}.4" "${logfile}.5" 2&gt;/dev/null
mv --force "${logfile}.3" "${logfile}.4" 2&gt;/dev/null
mv --force "${logfile}.2" "${logfile}.3" 2&gt;/dev/null
mv --force "${logfile}.1" "${logfile}.2" 2&gt;/dev/null
mv --force "${logfile}" "${logfile}.1" 2&gt;/dev/null
mv --force "${errfile}.6" "${errfile}.7" 2&gt;/dev/null
mv --force "${errfile}.5" "${errfile}.6" 2&gt;/dev/null
mv --force "${errfile}.4" "${errfile}.5" 2&gt;/dev/null
mv --force "${errfile}.3" "${errfile}.4" 2&gt;/dev/null
mv --force "${errfile}.2" "${errfile}.3" 2&gt;/dev/null
mv --force "${errfile}.1" "${errfile}.2" 2&gt;/dev/null
mv --force "${errfile}" "${errfile}.1" 2&gt;/dev/null
echo "log-rotate done."
else
echo "log-rotate not possible."
fi;
}
do_showlog() {
echo "-------------------------------------------------------------------------------"
tail "$errfile"
echo "-------------------------------------------------------------------------------"
tail "$logfile"
echo "-------------------------------------------------------------------------------"
}
do_usage() {
echo "Usage: {start|stop|status|restart|logrotate|startdelayed|showlog}"
}
case "$1" in
start)
do_start
;;
stop)
do_stop
;;
status)
do_status
;;
restart)
do_restart
;;
startdelayed)
do_startdelayed
;;
logrotate)
do_logrotate
;;
showlog)
do_showlog
;;
*)
do_usage
;;
esac
exit 0
######################################################################################################
</pre>
<h3>5. Reverse-Proxy Setup</h3>
<p>
You can run i2p-tools also behind your normal web-server (reverse-proxy).
<p>
The web-server handles the TLS handshake, encryption, SSL Certificate and the logfiles.
But you don't need the scripts su3.php and the shell cronjob for creating su3-files.
i2p-tools is running "behind" the web-server, without TLS management, only bind to
local interface 127.0.0.1 and is handling complete building and handling of su3-files.
<p>
Run i2p-tools with this command:
<pre>
i2p-tools reseed --signer test@test.de \
--key /path_to/test_at_test.de.pem \
--netdb /path_to/netDb \
--port=8443 \
--ip 127.0.0.1 \
--trustProxy
</pre>
Important notes for this special setup:
<ul>
<li>do *not* specify --tlsHost, --tlsCert or --tlsKey on the command-line
<li>"ip 127.0.0.1" binds the program only to local interface
<li>"trustProxy" uses the "X-Forwarded-For" to get the real client IP
</ul>
"trustProxy" uses the "X-Forwarded-For" to get the real client IP
<p>
nginx configuration example:
</p>
<pre>
location / {
proxy_pass http://127.0.0.1:8443;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
}
</pre>
<p>
Apache (untested - feedback would be appreciated)
</p>
<pre>
ProxyRequests Off
&lt;Proxy *&gt;
Order deny,allow
Allow from all
&lt;/Proxy&gt;
ProxyPass / http://127.0.0.1:8443/
ProxyPassReverse / http://127.0.0.1:8443/
</pre>
<p>
<p>
and for X-Forwarded-For:
<pre>
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
</pre>
<p>
Additionally, ensure that your webserver uses these suggested settings for Strong SSL Security (visit <a href="https://cipherli.st/" target="_blank">CipherLi.st</a> for the latest settings). A sample configuration is provided below.
</p>
<p>
Apache
</p>
<pre>
SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder On
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
Header always set X-Frame-Options DENY
Header always set X-Content-Type-Options nosniff
# Requires Apache >= 2.4
SSLCompression off
SSLUseStapling on
SSLStaplingCache "shmcb:logs/stapling-cache(150000)"
# Requires Apache >= 2.4.11
SSLSessionTickets Off
</pre>
<p>
nginx (remember to replace '$DNS-IP-1' & '$DNS-IP-2' with 2 trusted DNS servers)
</p>
<pre>
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
ssl_ecdh_curve secp384r1; # Requires nginx >= 1.1.0
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off; # Requires nginx >= 1.5.9
ssl_stapling on; # Requires nginx >= 1.3.7
ssl_stapling_verify on; # Requires nginx => 1.3.7
resolver $DNS-IP-1 $DNS-IP-2 valid=300s;
resolver_timeout 5s;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
</pre>
<p>
Complete nginx configuration (sample)
<p>
<pre>
user nobody;
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
server {
listen $IP_ADDRESS:443 ssl;
server_name $DOMAIN;
ssl_certificate keys/fullchain.pem;
ssl_certificate_key keys/privkey.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
ssl_ecdh_curve secp384r1; # Requires nginx >= 1.1.0
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off; # Requires nginx >= 1.5.9
ssl_stapling on; # Requires nginx >= 1.3.7
ssl_stapling_verify on; # Requires nginx => 1.3.7
resolver $DNS_IP_1 $DNS_IP_2 valid=300s;
resolver_timeout 5s;
ssl_prefer_server_ciphers on;
ssl_dhparam keys/dh.pem;
server_tokens off;
charset utf8;
location /i2pseeds.su3 {
proxy_pass http://127.0.0.1:8443;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
}
}
}
</pre>
<h3>6. Convert Existing Java Keystore to crt- and pem-file</h3>
<p>
@ -844,97 +360,6 @@ openssl x509 -in ${file}.pem -out xxxxx_at_mail.i2p.crt
######################################################################################################
</pre>
<h3>5. Seamless SSL-Certificate Exchange</h3>
<p>
The update/exchange of an already existing self-signed certificates has to be correct timed
on server *and* client side. Considering thousands of clients (many with older I2P version) the exchange
will not be seamless possible and will have very bad impact on many clients: reseed won't work for them.
<p>
To avoid this issue and make the exchange as smooth as possible follow these simple steps:
<ol>
<li>Generate a new SSL-certificate NOW, but do NOT implement it on server
<li>Send the new SSL-certificate to us to perform a roll-out towards clients NOW
<li>WAIT some month, e.g. 3-4 i2p-releases
<li>New SSL-certificate is now hopefully present on many clients (in parallel to the current/old one)
<li>THEN exchange the SSL-certificate on server
</ol>
<p>
This idea based on the fact, that you can provide in i2p/certificates/ssl more than one crt-file for a server, e.g.
server.com.crt and server.com2.crt
<h3>6. Reseed Server Domain/URL/Port Exchange</h3>
<p>
You are already operating a reseed server but want to change your Domain/URL/Port?
To make the exchange as smooth as possible for many clients please follow these steps if possible:
<ol>
<li>Setup an additional reseed instance at the new Domain/URL/Port
<li>We include the new URL into I2P source NOW and delete the old URL NOW
<li>Both of your reseed instances have to run some time in parallel
<li>WAIT some month, e.g. 3-4 i2p-releases
<li>New URL is now hopefully present on many clients
<li>THEN shutdown the old reseed instance
</ol>
<h3>7. Tests</h3>
<p>
Some simple pre-test: test the website and fetch
<pre>
wget --user-agent="Wget/1.11.4" \
-O /tmp/test.su3 \
--no-check-certificate https://your-server.com:PORT/i2pseeds.su3
</pre>
Replace "PORT" with default 443 or your chosen server setting.
Inspect the fetched file.:
Some simple pre-test: test the website and fetch
<pre>
zipinfo -z /tmp/test.su3
</pre>
<p>
Replace "--no-check-certificate" with "--ca-certificate=~/i2p/certificates/ssl/your-server.com.crt"
which contains the path to your local public SSL-certificate to check also your ssl-certificate chain.
<p>
Confirm the following:
<ul>
<li>SSL-certificate chain valid?
<li>The su3-files can be downloaded?
<li>Contains &gt; 50 dat-files?
<li>And is always the same for one client-IP?
<li>Other client-IP's gets another file?
<li>Clients has no direct access to complete folder e.g. https://your-server.com/su3/ ?
</ul>
<p>
Do a real reseed test on *another* I2P router machine:
<ul>
<li>Include manually new SSL-certificate into i2p installation: ~/i2p/certificates/ssl/
<li>Include manually new public reseed key into i2p installation: ~/i2p/certificates/reseed/
<li>http://localhost:7657/configreseed --&gt; remove all reseed hosts
<li>Add the new reseed host e.g. "https://your-server.com/" *without* trailing "i2pseeds.su3"
<li>Save and Shutdown router.
<li>Clear netdb: empty folder ./i2p/netDb.
<li>Restart I2P and watch the I2P router log:
<pre>
2014/10/13 23:01:02 | Reseed start
2014/10/13 23:01:02 | Reseeding from https://your-server/i2pseeds.su3
2014/10/13 23:01:05 | INFO: xx files extracted to /tmp/i2p-V2qudTbd.tmp/reseeds-1010682701
2014/10/13 23:01:05 | Reseed got xx router infos from https://your-server.com/i2pseeds.su3 with 0 errors
2014/10/13 23:01:06 | Reseed complete, xx received
</pre>
</ul>
<h3>8. Contact Reseed Maintainer</h3>
<p>