Discussion:
Strange error in catalina.out: "SEVERE: Error initializing endpoint java.net.BindException: Address already in use <null>:8443"
Christian Munive
2014-09-15 22:27:43 UTC
Permalink
Hi. I'm still relatively new to Shibboleth SW. I could succesfully set up
some IdP and SP's (with their optional EDS's) and a CDS. So far, so good.
But I noticed a some errors in my catalina.out, that I didn't notice before
(since the servers where up and running). The error is the following:

"SEVERE: Error initializing endpoint java.net.BindException: Address
already in use <null>:8443"

(The original in spanish is: "GRAVE: Error inicializando punto final
(endpoint) java.net.BindException: La dirección ya se está usando
<null>:8443")

And it it in every IdP I configured. The basic set up of my IdP machines
(either virtual or real) is:
- 64 bit architecture, 1 GB RAM minimun, 32 GB HD minimun
- Ubuntu Server 14.04.1
- Apache 2.4.7
- Tomcat 6.0.39
- Oracle Java 1.7.0_67
- OpenLDAP 2.4.31
- Shibboleth IdP 2.4.1

I'm using the recommended library "tomcat6-dta-ssl-1.0.0.jar" for SOAP
endpoints.

Some interesting bits of the confguration files:

/etc/tomcat6/server.xml

<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
URIEncoding="UTF-8"
redirectPort="8443" />

<Connector port="8443"
protocol="org.apache.coyote.http11.Http11Protocol"

sslImplementationName="edu.internet2.middleware.security.tomcat6$
scheme="https" SSLEnabled="true" clientAuth="want"
keystoreFile="/opt/shibboleth-idp/credentials/idp.jks"
keystorePass="changeit" />

<Connector port="8009" address="127.0.0.1" enableLookups="false"
redirectPort="8443" protocol="AJP/1.3"
tomcatAthentication="false" />

/etc/apache2/sites-enabled/idp.conf

Listen 443
<VirtualHost _default_:443>
ServerName ubuntu-workstation.inictel-uni.edu.pe:433
ServerAdmin cmunive-ABQWi6dheEev8wKtCOhL+yYViR+***@public.gmane.org

ErrorLog ${APACHE_LOG_DIR}/idp_443_error.log
TransferLog ${APACHE_LOG_DIR}/idp_443_transfer.log
CustomLog ${APACHE_LOG_DIR}/idp_443_custom.log combined
LogLevel warn

SSLEngine on
SSLOptions -StdEnvVars +ExportCertData

SSLCertificateFile /etc/apache2/ssl/apache.crt
SSLCertificateKeyFile /etc/apache2/ssl/apache.key

ProxyRequests Off

<Proxy ajp://localhost:8009>
Allow from all
</Proxy>

ProxyPass /idp ajp://localhost:8009/idp retry=5

<Files ~ "\.(cgi|shtml|phtml|php3?)$">
SSLOptions +StdEnvVars
</Files>

<Directory "/var/www/cgi-bin">
SSLOptions +StdEnvVars
</Directory>

SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
</VirtualHost>
Listen 8443
<VirtualHost _default_:8443>
ServerName ubuntu-workstation.inictel-uni.edu.pe:8443
ServerAdmin cmunive-ABQWi6dheEev8wKtCOhL+yYViR+***@public.gmane.org

SSLEngine on
SSLOptions -StdEnvVars +ExportCertData

SSLCertificateFile /opt/shibboleth-idp/credentials/idp.crt
SSLCertificateKeyFile /opt/shibboleth-idp/credentials/idp.key

ErrorLog ${APACHE_LOG_DIR}/idp_8443_error.log
TransferLog ${APACHE_LOG_DIR}/idp_8443_transfer.log
CustomLog ${APACHE_LOG_DIR}/idp_8443_custom.log combined
LogLevel warn

ProxyPass /idp ajp://localhost:8009/idp retry=2
ProxyPassReverse /idp ajp://localhost:8009/idp

<Files ~ "\.(cgi|shtml|phtml|php3?)$">
SSLOptions +StdEnvVars
</Files>

<Directory "/var/www/cgi-bin">
SSLOptions +StdEnvVars
</Directory>

SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
</VirtualHost>

Like I said, it's not a problem that prevents the normal procedures; I can
log in to secured resources from those IdP's... but those errors shouldn't
be there; I probably missed something while configuring those machines.

Please, help me. If you guys need any other info, I'll try to post it as
soon as I can. Thanks in advance.
Cantor, Scott
2014-09-15 22:41:51 UTC
Permalink
Post by Christian Munive
Like I said, it's not a problem that prevents the normal procedures; I
can log in to secured resources from those IdP's... but those errors
shouldn't be there; I probably missed something while configuring those
machines.
You can't tell both Apache and Tomcat to listen on the same port.

-- Scott
--
To unsubscribe from this list send an email to users-unsubscribe-***@public.gmane.org
Peter Schober
2014-09-16 09:50:37 UTC
Permalink
Chrsitian,
Post by Christian Munive
I'm using the recommended library "tomcat6-dta-ssl-1.0.0.jar" for
SOAP endpoints.
Seems you're following two different (and incompatible) sets of
instructions, and trying to merge them into one system.

You'll have to decide whether you want Apache httpd in the mix or
not. The above extension for Apache Tomcat is only needed if you don't
have httpd running at all and instead rely on Tomcat as a webserver on
both ports 443 /and/ 8443.

Either way will work: The dta extension allows to run only one server
process (Tomcat) instead of two (Tomcat and httpd) but is only
officially supported for Tomcat6 (although there's a contributed
extension for Tomcat7 that seems to work just fine).
Getting authentication for ECP set up seems a bit easier with httpd in
front, but can also be done with Tomcat solo.

In any case you'll have to either remove httpd from the mix and
configure Tomcat for https on port 443 also (i.e., running only
Tomcat) /or/ remove all connectors from Tomcat's server.xml except the
AJP one on port 8009, and restart both httpd and Tomcat (running httpd
on all external ports, and Tomcat only internally).
The second variant seems a bit easier given your existing configuration.

Best regards,
-peter
--
To unsubscribe from this list send an email to users-unsubscribe-***@public.gmane.org
Christian Munive
2014-09-16 14:19:00 UTC
Permalink
I see... thanks Peter. Yeah, I was trying to follow these instructions:

https://www.switch.ch/aai/docs/shibboleth/SWITCH/latest/idp/deployment/

But also including the instructions from the main site:

https://wiki.shibboleth.net/confluence/display/SHIB2/IdPApacheTomcatPrepare

I just tried what you recommended (using the port 443 only) and the problem
went away. I'll give it a thought and see which port / configuration might
be the better one.

Oh, and I configured a CDS to practice and learn a bit. It might be
implemented in the end (probably not), but now I have some idea of how to
make it work, just in case.

Thanks for your help guys.


Christian Munive.
Post by Peter Schober
Chrsitian,
Post by Christian Munive
I'm using the recommended library "tomcat6-dta-ssl-1.0.0.jar" for
SOAP endpoints.
Seems you're following two different (and incompatible) sets of
instructions, and trying to merge them into one system.
You'll have to decide whether you want Apache httpd in the mix or
not. The above extension for Apache Tomcat is only needed if you don't
have httpd running at all and instead rely on Tomcat as a webserver on
both ports 443 /and/ 8443.
Either way will work: The dta extension allows to run only one server
process (Tomcat) instead of two (Tomcat and httpd) but is only
officially supported for Tomcat6 (although there's a contributed
extension for Tomcat7 that seems to work just fine).
Getting authentication for ECP set up seems a bit easier with httpd in
front, but can also be done with Tomcat solo.
In any case you'll have to either remove httpd from the mix and
configure Tomcat for https on port 443 also (i.e., running only
Tomcat) /or/ remove all connectors from Tomcat's server.xml except the
AJP one on port 8009, and restart both httpd and Tomcat (running httpd
on all external ports, and Tomcat only internally).
The second variant seems a bit easier given your existing configuration.
Best regards,
-peter
--
To unsubscribe from this list send an email to
Peter Schober
2014-09-16 15:39:59 UTC
Permalink
Post by Christian Munive
https://www.switch.ch/aai/docs/shibboleth/SWITCH/latest/idp/deployment/
https://wiki.shibboleth.net/confluence/display/SHIB2/IdPApacheTomcatPrepare
Yeah, you can't combine those. The SWITCH guide uses httpd (and is
complete/sufficient by itself), the Shib wiki only has the
instructions to add SOAP support to Tomcat when using Tomcat solo
(there's your conflict with httpd and the SWITCH docs).
The Shib wiki also does not detail setting up TLS/SSL for port 443
(since this is not Shib specific).

If you want to try or compare yet another set of third party
documentation (for Tomcat solo, incl TLS setup) have a look at my own:
https://wiki.univie.ac.at/display/federation/Shibboleth+IDP+2.4
Concact me off-list for any questions about that, of course.
Post by Christian Munive
I just tried what you recommended (using the port 443 only) and the
problem went away.
I did not say anything that amounts to "using the port 443 only":
For Tomcat+httpd you'd use Tomcat on port 8009 only, and let httpd
proxy and serve 443 and 8443.
For Tomcat solo you'd serve 443 and 8443 from Tomcat itself.
Post by Christian Munive
I'll give it a thought and see which port / configuration might be
the better one.
Somewhat academic, but things to consider:

* 2 servers (Tomcat+httpd) needed for 1 purpose vs. 1 server (Tomcat solo):

* ease of running the JVM as non-root (also depends on
OS/distribution; it's trivial on Debian/Ubuntu; I have a locally
rolled SRPM for authbind if you wanted to have the same on RHEL-like
systems):

* ease of configuring TLS/SSL (though with PKCS#12 support in Tomcat
the pain of managing JKS goes away, see my documention above):

* versions of Tomcat available through package management (for
security updates) in the OS/distribution you're using, and the
availability of the DelegateToApplication extension for Tomcat:

* easy of adding container-based authentication for ECP

These are the main points, I feel.
-peter
--
To unsubscribe from this list send an email to users-unsubscribe-***@public.gmane.org
Christian Munive
2014-09-17 21:26:53 UTC
Permalink
Hi. Yep, I just finished setting up a couple of IdPs, one with Apache +
Tomcat, and another with Tomcat alone, the later following your guide.

The errors in catalina.out are gone and both work nicely. And you're right,
it's more simple / easy to use Tomcat alone. I got a bit confused with the
configuration instructions, trying to "complete" the SWITCH configuration
with bits from the Shib guide... but it's clear for me now.

Thanks again.
Post by Christian Munive
Post by Christian Munive
https://www.switch.ch/aai/docs/shibboleth/SWITCH/latest/idp/deployment/
https://wiki.shibboleth.net/confluence/display/SHIB2/IdPApacheTomcatPrepare
Yeah, you can't combine those. The SWITCH guide uses httpd (and is
complete/sufficient by itself), the Shib wiki only has the
instructions to add SOAP support to Tomcat when using Tomcat solo
(there's your conflict with httpd and the SWITCH docs).
The Shib wiki also does not detail setting up TLS/SSL for port 443
(since this is not Shib specific).
If you want to try or compare yet another set of third party
https://wiki.univie.ac.at/display/federation/Shibboleth+IDP+2.4
Concact me off-list for any questions about that, of course.
Post by Christian Munive
I just tried what you recommended (using the port 443 only) and the
problem went away.
For Tomcat+httpd you'd use Tomcat on port 8009 only, and let httpd
proxy and serve 443 and 8443.
For Tomcat solo you'd serve 443 and 8443 from Tomcat itself.
Post by Christian Munive
I'll give it a thought and see which port / configuration might be
the better one.
* ease of running the JVM as non-root (also depends on
OS/distribution; it's trivial on Debian/Ubuntu; I have a locally
rolled SRPM for authbind if you wanted to have the same on RHEL-like
* ease of configuring TLS/SSL (though with PKCS#12 support in Tomcat
* versions of Tomcat available through package management (for
security updates) in the OS/distribution you're using, and the
* easy of adding container-based authentication for ECP
These are the main points, I feel.
-peter
--
To unsubscribe from this list send an email to
Peter Schober
2014-09-16 09:53:52 UTC
Permalink
Post by Christian Munive
Hi. I'm still relatively new to Shibboleth SW. I could succesfully set up
some IdP and SP's (with their optional EDS's) and a CDS.
Note that you probably don't want to run the current CDS as is, as
it's neither as easy to deploy/configure as it could be, nor is the
user interface as up-to-date as e.g. the EDS' (or the SWITCHwayf's).
(Unless you apply some of the changes the UKfederation has done, for
example.)
Personally I wouldn't bother with the CDS, unless you positively
need something in Java.
-peter
--
To unsubscribe from this list send an email to users-unsubscribe-***@public.gmane.org
Loading...