[Struts] <bean:include> i.c.m. https / ssl

[Standeman]

Ik heb een leuke web applicatie ontwikkeld dat op onze develop server draait als een zonnetje. Aangezien de deadline van het project naderd bedacht ik dat we op het onze acceptatie server moest gaan zetten zodat gebruikers kunnen gaan testen.

Eenmaal gedeployed kreeg ik de schrik van mijn leven. Het blijkt dat de <bean:include> niet helemaal lekker schijnt samen te werken met SSL (https).

Op onze dev-server wordt namelijk helemaal geen gebruik gemaakt van https, maar op onze acceptatie servers wel.

de exception die ik krijg ziet er als volgt uit:

code:

javax.servlet.jsp.JspException: Exception opening resource 
https://acceptatie.foo.com/FreeBees/FreeBeeMenu.do: 
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: 
No trusted certificate found

de code die ik gebruik is vrij simpel:

Java:

            <bean:include id="menu" page="/FreeBeeMenu.do" />
            <bean:write name="menu" filter="false" />

Ik ben toen een beetje gaan testen waardoor ik er achter ben gekomen dat de opties <jsp:include> en <c:import> geen oplossing zijn.

Via google kom ik ongeveer 6 x dezelfde post op verschillende fora tegen waar geen bruikbaar antwoord bijzit. Via GoT krijg ik zelfs geen hits op <bean:include>

Wie o Wie is hier al eens eerder tegen aan gelopen?

p.s. Wanneer ik https://acceptatie.foo.com/FreeBees/FreeBeeMenu.do via bijv. een link aanroep, gaat het allemaal wel goed.

[ Voor 10% gewijzigd door Standeman op 18-01-2006 10:44 ]

[Confusion]

Waar ik wel mee te maken heb gehad is client-side authentication. Hierbij treed je als Certificate Authority op, signeer je de certificaten van je clienten met je CA-certificaat en stop je dat CA-certificaat vervolgens in de trustedStore van de SSL Connector van de Tomcat server. Op dat moment kunnen alleen mensen met een gesigneerd certificaat een https verbinding met je maken.

Je zou het misschien op kunnen lossen door een certificaat te signeren met een ander certificaat, de laatste in je trusted certificate storage van je appserver te gooien en te zorgen dat server die de bean opvraagt het gesigneerde certificaat aanbiedt.

Maar misschien ligt het gewoon aan de afstelling van je appserver, die van zichzelf al zo restrictief is ingesteld dat hij een client side certificaat vereist. Dat is bij Tomcat standaard niet zo. Een misschien makkelijkere oplossing is even de config van die server doorspitten.

[Verwijderd]

Ik weet weinig van struts (heb er namelijk niet zo'n hoge pet van op) maar probeer je nu feitelijk intern over https een pagina te includen???

[Janoz]

In principe komt het daar wel op neer. Ikzelf vind het ook een beetje een wonderlijke constructie. Wat is de reden om een complete action als include te gebruiken?

Ik denk namelijk dat dit niet je enige probleem gaat worden met deze methode. Ik kan me goed voorstellen dat je ook problemen met sessies en remote user gaat krijgen.

[ Voor 35% gewijzigd door Janoz op 18-01-2006 11:06 ]

[Standeman]

Janoz schreef op woensdag 18 januari 2006 @ 11:05:
In principe komt het daar wel op neer. Ikzelf vind het ook een beetje een wonderlijke constructie. Wat is de reden om een complete action als include te gebruiken?

Ik denk namelijk dat dit niet je enige probleem gaat worden met deze methode. Ik kan me goed voorstellen dat je ook problemen met sessies en remote user gaat krijgen.

Eigenlijk ben ik nu een oude app aan het ombouwen waarin in elke jsp een menu stond. Deze applicatie wordt nu omgebouwd en van dat menu heb ik nu een action gebouwd welke in de JSP van een andere action wordt ge-include. (uiteraard niet slechts op 1 plaats).

Of dit slim is weet ik nog niet.

Ik denk dat ik inmiddels de oorzaak wel enigzins logisch kan redeneren:
Een bean:include is vergelijkbaar als een java app (in dit geval mijn appserver) welke een nieuwe ssl connectie opent naar je appserver. Aangezien ons certificaat niet in de keystore staat wordt de connectie geweigerd.
Ik heb mijn theorie nog niet getest, maar vinden jullie dit logisch klinken?

Met sessies heb ik nog geen enkel probleem gehad. Hoe bedoel je dat ik daar mogelijk problemen mee ga krijgen? En waarom is een vreemde constructie om een menu inc. benodigde functionaliteit in een action te stoppen?

[Verwijderd]

Standeman schreef op woensdag 18 januari 2006 @ 14:27:
Ik denk dat ik inmiddels de oorzaak wel enigzins logisch kan redeneren:
Een bean:include is vergelijkbaar als een java app (in dit geval mijn appserver) welke een nieuwe ssl connectie opent naar je appserver. Aangezien ons certificaat niet in de keystore staat wordt de connectie geweigerd.
Ik heb mijn theorie nog niet getest, maar vinden jullie dit logisch klinken?

Dit is precies waar ik in eerste instantie op doelde, dus ja dat vind ik aannemelijk

[Confusion]

Standeman schreef op woensdag 18 januari 2006 @ 14:27:
Ik denk dat ik inmiddels de oorzaak wel enigzins logisch kan redeneren:
Een bean:include is vergelijkbaar als een java app (in dit geval mijn appserver) welke een nieuwe ssl connectie opent naar je appserver. Aangezien ons certificaat niet in de keystore staat wordt de connectie geweigerd.
Ik heb mijn theorie nog niet getest, maar vinden jullie dit logisch klinken?

Ja, behalve dat, als je toegang tot de appserver hebt, je hem zo in kan stellen dat hij niet geeft om 'client'-side certificaten. Normale SSL verbindingen worden immers ook zonder certificaten opgezet.

[Casteloni]

Heb je toevallig een andere JDK draaien op de server? Of een ander OS? Ik kreeg deze melding namelijk ook, alleen dan niet direct gerelateerd aan struts. Na lang zoeken bleek dat de cacerts file niet helemaal up2date was.

[Standeman]

VampireSlayer schreef op woensdag 18 januari 2006 @ 16:14:
Heb je toevallig een andere JDK draaien op de server? Of een ander OS? Ik kreeg deze melding namelijk ook, alleen dan niet direct gerelateerd aan struts. Na lang zoeken bleek dat de cacerts file niet helemaal up2date was.

Aangezien ons certificaat niet in de keystore staat wordt de connectie geweigerd.

Ik moet 'm met de keytool nog even invoegen om te testen...