You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Jack <ja...@hotmail.com> on 2006/01/19 17:24:43 UTC
Server certificates for tomcat
Server certificate:
The certificate for the engine with alias "tomcat"
The certificate for a specific host
The certificate for a specific web-app
If a web-app doesn't have a certificate, it can be configured to use the
certificate of the host. Similarly, if a host doesn't have a certificate, it
can be configured to use the certificate of the engine. However, when a
web-app has a certificate, then this one should be used rather than always
using "tomcat".
clientAuth of https connector is not relevant, at this level (engine), ask
for a client's certificate, what is it for? It should be like this: If the
client is requesting a server resource that requires client authentication,
the server requests the client's certificate. If we don't ask for
certificate, then truststore config is irrelevant. "clientAuth" should be a
property of a web-app. Since web.xml doesn't specify it, it can be include
into the web-app context, context.xml.
At the host level, we have the same question, too.
At the web-app level, it is reasonable. This web-app asks for a client
certificate. And the UserManager will consult the usercontext of this
web-app for keystore & truststore information.
At present, what component does the verification of a client's certificate?
The connector/sslsupport should call the UserManager to do so.
Here, I don't know the reason why many people say the design of SSL doesn't
allow several domain name based certificates on the single IP.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Please consider this.
Posted by Jack <ja...@hotmail.com>.
I have read your reply. It is valuable to me. Thanks.
May I suggest this idea:
>> Server certificate:
>> The certificate for the engine with alias "tomcat"
>> The certificate for a specific host
>> The certificate for a specific web-app
>> If a web-app doesn't have a certificate, it can be configured to use the
>> certificate of the host. Similarly, if a host doesn't have a certificate,
>> it can be configured to use the certificate of the engine. However, when
>> a web-app has a certificate, then this one should be used rather than
>> always using "tomcat".
> Pretty much a pipe-dream, since the SSL protocol requires that the server
> send it's cert before it even knows the Host, much less the webapp :).
> There is pretty much no other place it can go other than with the
> Connector.
SSL component is a resource. The engine, virtual hosts, and web-apps are its
users. The resource could ask a certificate from its current user. The
engine is a subject, so it has a certificate in its own user context
(EngineUserConext). Each host is a subject, too. They all have their
respective certificates in their user contexts (HostUserConext). If a host
doesn't have a certificate, the engine certificate could be used. Any
web-app is a subject, too. Every web-app has its own certificate in
WebAppUserContext. If a web-app doesn't have a certificate, it could use
that of its host. Accessing all the information about a
user/entity/subject/program should be done with UserManager which in turn
will access the right UserContext. UserContext will access KeyManager &
TrustManager.
The SSL component should deal with UserManager to get information about its
users (Engine/Host/Web-app), and authenticate web clients.
I have post another thread suggesting to add the UserManager component.
Thank you for consideration!
jackzhp@hotmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: hopefully?
Posted by Bill Barker <wb...@wilshire.com>.
"Jack" <ja...@hotmail.com> wrote in message
news:dr2uuu$ckg$1@sea.gmane.org...
> "Bill Barker" <wb...@wilshire.com> wrote in message
> news:dr1h0f$u9s$1@sea.gmane.org...
>>> After a request & response, on the keep alive connection.
>>> The web server starts to negotiate an SSL support by sending a Hello
>>> request.
>> It won't, since it has no reason to renegotiate.
>> They will (hopefully) close the connection to port 80, and open a new
>> connection to port 443.
>> No, simply that practically no browser supports RFC2817
>> http://www.ietf.org/rfc/rfc2817.txt.
> Great! Thanks a lot. I got it. People have already work on this.
> RFC2817 is pretty comprehensive.
>
> It seems you didn't get my point, let me put in this way.
> Over a normal http connection (port 80),
> after the first request & response, the server sends "hello request".
> Is it easy for the broswer & tomcat turn the normal connection into ssl
> connection
> (still on port 80)?
Either the Connector is either expecting SSL or HTTP, but not both. The
browser won't do it either unless you specify a https URL. If you try this,
Tomcat will simply respond with a 400 (Bad Request), and close the socket
connection. You can see it by doing https://localhost:8080 against an
out-of-the-box Tomcat install.
>
> Thank you for your time.
>
> jackzhp@hotmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Related to msg "unprotected data transfer on ssl port"
Posted by Jack <ja...@hotmail.com>.
I forgot at that time, what I did to tomcat.
but it was true.
>SSL connector is defined on 8443 for my tomcat 5.5.12.
>https://localhost:8443/
>no response for long time,
>however, http://localhost:8443/
>I got everything, same as http://localhost/
It seems that at that time, I still don't know the native code for windows
causes the no response for long time problem.
After i delete native.dll. it becomes normal.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
hopefully?
Posted by Jack <ja...@hotmail.com>.
"Bill Barker" <wb...@wilshire.com> wrote in message
news:dr1h0f$u9s$1@sea.gmane.org...
>> After a request & response, on the keep alive connection.
>> The web server starts to negotiate an SSL support by sending a Hello
>> request.
> It won't, since it has no reason to renegotiate.
> They will (hopefully) close the connection to port 80, and open a new
> connection to port 443.
> No, simply that practically no browser supports RFC2817
> http://www.ietf.org/rfc/rfc2817.txt.
Great! Thanks a lot. I got it. People have already work on this.
RFC2817 is pretty comprehensive.
It seems you didn't get my point, let me put in this way.
Over a normal http connection (port 80),
after the first request & response, the server sends "hello request".
Is it easy for the broswer & tomcat turn the normal connection into ssl
connection
(still on port 80)?
Thank you for your time.
jackzhp@hotmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Thank you for your response. Please read this.
Posted by Bill Barker <wb...@wilshire.com>.
"Jack" <ja...@hotmail.com> wrote in message
news:dqusd0$aqi$1@sea.gmane.org...
> Hi,
> Mr. Barker,
>
> Thank you for your response. Your message is valuable.
>
>> No we don't. It's a new connection from Tomcat's point of view, totally
>> indisigushable from any other new connection.
> Yes. You are right,
>
> For most browsers, do you have an idea about what is going to happen for
> this?
>
They will (hopefully) close the connection to port 80, and open a new
connection to port 443.
> After a request & response, on the keep alive connection.
> The web server starts to negotiate an SSL support by sending a Hello
> request.
>
It won't, since it has no reason to renegotiate.
> If web browsers can process it correctly, then in such cases, it is
> possible to use the web-app certificate.
> Mr. Barker mentioned:
>>...., but practically no browser supports the protocol extension that
>>allows this, so it's currently not worth the effort of trying to support
>>it.
> Do you mean web browsers will just ignore the received Hello request?
>
No, simply that practically no browser supports RFC2817
http://www.ietf.org/rfc/rfc2817.txt.
> At present, RealmBase.hasUserDataPermission just redirect the request to
> https port.
> It doesn't do it in the way mentioned above.
>
Pretty much the only thing it can do. The SSL port will be different than
the normal HTTP port.
> I am looking forward to your opinion. Thanks.
>
> jackzhp@hotmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Thank you for your response. Please read this.
Posted by Jack <ja...@hotmail.com>.
Hi,
Mr. Barker,
Thank you for your response. Your message is valuable.
> No we don't. It's a new connection from Tomcat's point of view, totally
> indisigushable from any other new connection.
Yes. You are right,
For most browsers, do you have an idea about what is going to happen for
this?
After a request & response, on the keep alive connection.
The web server starts to negotiate an SSL support by sending a Hello
request.
If web browsers can process it correctly, then in such cases, it is possible
to use the web-app certificate.
Mr. Barker mentioned:
>...., but practically no browser supports the protocol extension that
>allows this, so it's currently not worth the effort of trying to support
>it.
Do you mean web browsers will just ignore the received Hello request?
At present, RealmBase.hasUserDataPermission just redirect the request to
https port.
It doesn't do it in the way mentioned above.
I am looking forward to your opinion. Thanks.
jackzhp@hotmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: My solutions to it, please read it.
Posted by Bill Barker <wb...@wilshire.com>.
"Jack" <ja...@hotmail.com> wrote in message
news:dquegd$8hi$1@sea.gmane.org...
>
> "Bill Barker" <wb...@wilshire.com> wrote in message
> news:dqpmpp$ktr$1@sea.gmane.org...
>>
>> Pretty much a pipe-dream, since the SSL protocol requires that the server
>> send it's cert before it even knows the Host, much less the webapp :).
>> There is pretty much no other place it can go other than with the
>> Connector.
> It works.
>
>> Not strictly true, but practically no browser supports the protocol
>> extension that allows this, so it's currently not worth the effort of
>> trying to support it.
> It should has nothing to do with browsers.
>
> Furthermore, I have report a bug on January 20, 2006. The KeyManager does
> not always return "tomcat".
> The bug is here:
>
> In the getKeyManagers of
> org.apache.tomcat.util.net.jsse.JSSE14SocketFactory
> kms = kmf.getKeyManagers();
> jacklog("return "+kms.length+" KeyManagers.");
> if (keyAlias != null)
> { if (JSSESocketFactory.defaultKeystoreType.equals(keystoreType))
> { keyAlias = keyAlias.toLowerCase();
> }
> for(int i=0; i<kms.length; i++)
> { kms[i] = new JSSEKeyManager((X509KeyManager)kms[i], keyAlias);
> } }
> return kms;
>
> When the keyAlias==null, we don't use our own JSSEKeyManager at all.
>
> If I change it to the following:
> kms = kmf.getKeyManagers();
> jacklog("return "+kms.length+" KeyManagers.");
> if (keyAlias != null)
> { if (JSSESocketFactory.defaultKeystoreType.equals(keystoreType))
> { keyAlias = keyAlias.toLowerCase();
> } }
> for(int i=0; i<kms.length; i++)
> { kms[i] = new JSSEKeyManager((X509KeyManager)kms[i], "whatever
> doesn't matter since we will choose later.");
> }
> return kms;
>
>
>
> And change the chooseServerAlias in JSSEKeyManager
> public String chooseServerAlias(String keyType, Principal[] issuers,
> Socket socket)
> { System.out.println("in chooseServerAliases with key type:"+keyType);
> if(issuers!=null)
> { System.out.println("\tissuers:"+issuers.length);
> for(int i=0;i<issuers.length;i++)
> { System.out.print("\t");
> System.out.println(issuers[i].toString());
> } }
> if(socket!=null)
> { System.out.println("\tsocket::"+socket.toString());
> }
> String
> delegateReturn=delegate.chooseServerAlias(keyType,issuers,socket);
> System.out.println("\tdelegate return:"+delegateReturn);
> String[] as=new String[2];
> as[0]="tomcat";
> as[1]="itsnows";
> System.out.println("\tplease choose 0:"+as[0]+" 1:"+as[1]);
> //JSSESocketFactory.pause();
> int c=0;
> giveup:
> while(c!=0x30&&c!=0x31)
> { try
> { c=System.in.read();
> }
> catch(Exception e)
> { System.out.println("\tException:"+e.getMessage());
> JSSESocketFactory.pause();
> c=0x30;
> break giveup;
> } }
> //return serverKeyAlias;
> return as[c-0x30];
> }
>
> I will have the opportunity to select a server certificate ("tomcat" or
> "itsnows") to send out.
>
I don't know about you, but I've got way better uses for my time than to sit
at a terminal selecting certs to send ;-).
> Now, it is clear that whenever javax.net.ssl needs a server certificate,
> it will call our KeyManager (JSSEKeyManager).
>
> If we know who is using the SSL at the moment, we know which certificate
> we should send out.
>
> In tomcat, we have only two types of SSL users: the engine or a web-app.
>
> If we redirect a connection to the SSL connector, we know which web-app is
> using the SSL, we should send the certificate of the web-app. If it
> doesn't have a certificate and it is configured to use the certificate of
> its virtual host, use the certificate of its virtual host.
>
No we don't. It's a new connection from Tomcat's point of view, totally
indisigushable from any other new connection.
>
>
> When a web user initiates an SSL connection, since we don't know which
> web-app the user wants to access, we can send the engine certificate.
>
Yeah, well, that's the rub. In a normal SSL connection, the server-cert is
only ever sent when the client initiates a SSL connection.
>
>
> If it is too much work or too costly to use security manager, we can just
> use a ThreadLocal object to record the user. Such an object can be put in
> our KeyManager (JSSEKeyManager) or other places. I suggest to keep it with
> the UserManager and we can use it for many other purpose. I don't think we
> need a stack to store the callers (the engine & web-apps).
>
>
In Tomcat (esp. with the HTTP/1.1 Connector), Threads are very long-lived
objects, and are reused for very many unrelated connections. This makes
ThreadLocal a pretty dangerous thing to use unless you are simply using
within one Request lifecycle.
>
> In UserManager, I wrote this (Can be put in JSSEKeyManager, too):
>
> public static ThreadLocal tlCaller=new ThreadLocal();
>
> private static Context engine;//the engine context
>
>
>
> //when we know the SSL is going to be used by a specific web-app, or the
> thread is going to run on a specific web-app
>
> public void attach(Context caller)
>
> { tlCaller.set(caller);
>
> }
>
>
>
> //When we know the SSL is no longer to be used by the specific web-app,
>
> //or the thread is going to stop running on the specific a web-app
>
> public void deattach()
>
> { tlCaller.set(engine);
>
> }
>
>
>
> //when catalina starts, this should be called by the engine.
>
> public void set(Context engine)
>
> { this.engine=engine;
>
> }
>
>
>
> The Caller (Context) should implement:
>
> String getCertificateAlias();//since getName has been used in other
> meaning, and getAlias doesn't carry enough info.
>
>
>
> Then in JSSEKeyManager, we implement
>
> public String chooseServerAlias(String keyType, Principal[] issuers,
> Socket socket)
>
> { return UserManager.tlCaller.getCertificateAlias();
>
> }
>
>
>
> Hi, guys, I believe that it can be done in this way. Do you know where we
> can call
>
This would be in your digester rules (which would necessarily change to
recognize your new tag).
> UserManager.set(engine); //we have only one engine, it will not be too
> difficult to find a good place.
>
> UserManager.attach(context); //The container of a web-app.
>
> UserManager.deattach();
>
>
>
> Furthermore, once we know which web-app the user wants to access, we
> could/should close the SSL connection using the engine certificate, and
> initiate a new SSL connection using the certificate of the web-app. You
> might think that it is too costly for this. That will be another little
> thing.
>
Closing it would be pretty much fatal ;-). However, it is possible to
renegotiate the connection. Since you seem to be interested in the
codebase, look at how JSSESupport.getPeerCertificateChain(true) does it
(yes, I know it's for client-certs, but the same thing could be done to
change the server-cert). And, yes, it's expensive. Also, I don't know
(since I've never tried :) how many browsers would freak out getting a
different server-cert on a renegotiate.
The new server-cert Subject-DN has to be the same (the DNS name of the
server), or the client will reject it. I suppose you could change the
signer (as long as the client still trusts it), or, say the Subject-OU. Of
course, there are much easier ways to pass information to the client than
through the server-cert :).
>
>
> Any opinion, please just reply or send me a message.
>
> jackzhp@hotmail.com
>
> Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
My solutions to it, please read it.
Posted by Jack <ja...@hotmail.com>.
"Bill Barker" <wb...@wilshire.com> wrote in message
news:dqpmpp$ktr$1@sea.gmane.org...
>
> Pretty much a pipe-dream, since the SSL protocol requires that the server
> send it's cert before it even knows the Host, much less the webapp :).
> There is pretty much no other place it can go other than with the
> Connector.
It works.
> Not strictly true, but practically no browser supports the protocol
> extension that allows this, so it's currently not worth the effort of
> trying to support it.
It should has nothing to do with browsers.
Furthermore, I have report a bug on January 20, 2006. The KeyManager does
not always return "tomcat".
The bug is here:
In the getKeyManagers of org.apache.tomcat.util.net.jsse.JSSE14SocketFactory
kms = kmf.getKeyManagers();
jacklog("return "+kms.length+" KeyManagers.");
if (keyAlias != null)
{ if (JSSESocketFactory.defaultKeystoreType.equals(keystoreType))
{ keyAlias = keyAlias.toLowerCase();
}
for(int i=0; i<kms.length; i++)
{ kms[i] = new JSSEKeyManager((X509KeyManager)kms[i], keyAlias);
} }
return kms;
When the keyAlias==null, we don't use our own JSSEKeyManager at all.
If I change it to the following:
kms = kmf.getKeyManagers();
jacklog("return "+kms.length+" KeyManagers.");
if (keyAlias != null)
{ if (JSSESocketFactory.defaultKeystoreType.equals(keystoreType))
{ keyAlias = keyAlias.toLowerCase();
} }
for(int i=0; i<kms.length; i++)
{ kms[i] = new JSSEKeyManager((X509KeyManager)kms[i], "whatever
doesn't matter since we will choose later.");
}
return kms;
And change the chooseServerAlias in JSSEKeyManager
public String chooseServerAlias(String keyType, Principal[] issuers,
Socket socket)
{ System.out.println("in chooseServerAliases with key type:"+keyType);
if(issuers!=null)
{ System.out.println("\tissuers:"+issuers.length);
for(int i=0;i<issuers.length;i++)
{ System.out.print("\t");
System.out.println(issuers[i].toString());
} }
if(socket!=null)
{ System.out.println("\tsocket::"+socket.toString());
}
String
delegateReturn=delegate.chooseServerAlias(keyType,issuers,socket);
System.out.println("\tdelegate return:"+delegateReturn);
String[] as=new String[2];
as[0]="tomcat";
as[1]="itsnows";
System.out.println("\tplease choose 0:"+as[0]+" 1:"+as[1]);
//JSSESocketFactory.pause();
int c=0;
giveup:
while(c!=0x30&&c!=0x31)
{ try
{ c=System.in.read();
}
catch(Exception e)
{ System.out.println("\tException:"+e.getMessage());
JSSESocketFactory.pause();
c=0x30;
break giveup;
} }
//return serverKeyAlias;
return as[c-0x30];
}
I will have the opportunity to select a server certificate ("tomcat" or
"itsnows") to send out.
Now, it is clear that whenever javax.net.ssl needs a server certificate, it
will call our KeyManager (JSSEKeyManager).
If we know who is using the SSL at the moment, we know which certificate we
should send out.
In tomcat, we have only two types of SSL users: the engine or a web-app.
If we redirect a connection to the SSL connector, we know which web-app is
using the SSL, we should send the certificate of the web-app. If it doesn't
have a certificate and it is configured to use the certificate of its
virtual host, use the certificate of its virtual host.
When a web user initiates an SSL connection, since we don't know which
web-app the user wants to access, we can send the engine certificate.
If it is too much work or too costly to use security manager, we can just
use a ThreadLocal object to record the user. Such an object can be put in
our KeyManager (JSSEKeyManager) or other places. I suggest to keep it with
the UserManager and we can use it for many other purpose. I don't think we
need a stack to store the callers (the engine & web-apps).
In UserManager, I wrote this (Can be put in JSSEKeyManager, too):
public static ThreadLocal tlCaller=new ThreadLocal();
private static Context engine;//the engine context
//when we know the SSL is going to be used by a specific web-app, or the
thread is going to run on a specific web-app
public void attach(Context caller)
{ tlCaller.set(caller);
}
//When we know the SSL is no longer to be used by the specific web-app,
//or the thread is going to stop running on the specific a web-app
public void deattach()
{ tlCaller.set(engine);
}
//when catalina starts, this should be called by the engine.
public void set(Context engine)
{ this.engine=engine;
}
The Caller (Context) should implement:
String getCertificateAlias();//since getName has been used in other meaning,
and getAlias doesn't carry enough info.
Then in JSSEKeyManager, we implement
public String chooseServerAlias(String keyType, Principal[] issuers, Socket
socket)
{ return UserManager.tlCaller.getCertificateAlias();
}
Hi, guys, I believe that it can be done in this way. Do you know where we
can call
UserManager.set(engine); //we have only one engine, it will not be too
difficult to find a good place.
UserManager.attach(context); //The container of a web-app.
UserManager.deattach();
Furthermore, once we know which web-app the user wants to access, we
could/should close the SSL connection using the engine certificate, and
initiate a new SSL connection using the certificate of the web-app. You
might think that it is too costly for this. That will be another little
thing.
Any opinion, please just reply or send me a message.
jackzhp@hotmail.com
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Server certificates for tomcat
Posted by Bill Barker <wb...@wilshire.com>.
"Jack" <ja...@hotmail.com> wrote in message
news:dqoehb$2ll$1@sea.gmane.org...
> Server certificate:
>
> The certificate for the engine with alias "tomcat"
>
> The certificate for a specific host
>
> The certificate for a specific web-app
>
>
>
> If a web-app doesn't have a certificate, it can be configured to use the
> certificate of the host. Similarly, if a host doesn't have a certificate,
> it can be configured to use the certificate of the engine. However, when a
> web-app has a certificate, then this one should be used rather than always
> using "tomcat".
>
Pretty much a pipe-dream, since the SSL protocol requires that the server
send it's cert before it even knows the Host, much less the webapp :).
There is pretty much no other place it can go other than with the Connector.
>
>
> clientAuth of https connector is not relevant, at this level (engine), ask
> for a client's certificate, what is it for? It should be like this: If the
> client is requesting a server resource that requires client
> authentication, the server requests the client's certificate. If we don't
> ask for certificate, then truststore config is irrelevant. "clientAuth"
> should be a property of a web-app. Since web.xml doesn't specify it, it
> can be include into the web-app context, context.xml.
>
>
The 'clientAuth' on the Connector is a sledgehammer that some people find
useful in a limited number of cases. <auth-method>CLIENT-CERT</auth-method>
in your web.xml does pretty much what you want.
JSSE (which is what actually handles the SSL protocol stuff) wants to
validate the client-cert up to a trusted root CA, so it needs the union of
the webapp's root CAs in its truststore to function. You can always use a
Filter to check that the cert is signed by the correct CA for the webapp.
>
> At the host level, we have the same question, too.
>
>
>
> At the web-app level, it is reasonable. This web-app asks for a client
> certificate. And the UserManager will consult the usercontext of this
> web-app for keystore & truststore information.
>
>
>
> At present, what component does the verification of a client's
> certificate? The connector/sslsupport should call the UserManager to do
> so.
>
>
There are parts to this. JSSE verifies that the certificate is valid (e.g.
not expired), and that the chain can be traced to a trusted root CA. If
this fails, none of the Tomcat code gets a chance to intervene: The
connection is simply closed. Later your configured Realm attempt to map the
cert to an actual user, and resolves the roles. However, currently all of
the Realms that ship with Tomcat only work on the actual client-cert subject
(so a cert signed by trusted CA1 is the same as a cert signed by trusted
CA2). You would need your own custom Realm if you needed to differentiate
certs based on the signer chain.
>
> Here, I don't know the reason why many people say the design of SSL
> doesn't allow several domain name based certificates on the single IP.
Not strictly true, but practically no browser supports the protocol
extension that allows this, so it's currently not worth the effort of trying
to support it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org