6932016
|
Verisign EV certificate chain issue with new built-in
CA root.
If you are using Verisign EV 2048-bit SSL
web server certificates, some older browsers might give a Certificate
Authority Not Trusted warning after you upgrade from an earlier
version of Web Server 7.0 to Web Server 7.0 Update 8.
Workaround:
-
Stop Web Server.
-
Change to the config directory
of the Web Server instance.
-
List the Root Certs module.
modutil -list -nocertdb -dbdir .
|
-
Delete the Root Certs module.
modutil -dbdir . -delete 'Root Certs'
|
-
Confirm that the Root Certs module is deleted.
modutil -list -nocertdb -dbdir .
|
-
Start Web Server.
Note –
If you upgrade Web Server after performing this
workaround, you must repeat this workaround after the upgrade. Otherwise,
the built-in VeriSign Class 3 Public Primary CA - G5 CA root certificate
appears again and some older browsers might give a Certificate Authority
Not Trusted warning again.
|
6407877
|
Incorrect migration occurs while migrating
from Web Server 6.0 to 7.0 if the installed.pkg file is not found.
In Web Server 6.0 to 7.0 migration, if the installed.pkg file
is missing, Web Server incorrectly migrates the NSServlet entries
in the magnus.conf file.
|
6490124
|
6.x -> 7.0: Migrated scheduled events still
points to 6.x paths in the server.xml file.
|
6502529
|
6.1->7.0: Migration does not handle relative
path set for search-collection-dir correctly.
During instance migration, specifying a relative path for the target
path into which the search collections should be copied, results in the search
collection directory being created with respect to the config-store.
When the instance is instantiated, the indexes are created without properly
migrating the search collections.
|
6502769
|
6.x->7.0: Migration ignores any "document-root"
NameTrans specified in the obj.conf file.
|
6498806
|
On Windows, Web Server Admin Console does not
appropriately warn users during migration.
Administration Server does not detect if the selected new configuration
or the service name already exists on Windows and hence does not appropriately
warn the users to select a different configuration name or suggest a different
configuration name as default.
|
6500509
|
Web Server 7.0 migration tool is unable to successfully
migrate from Web Server 6.1 if it has Root Certs installed in it.
|
6747123
|
The request processing behavior has changed
in Sun Java System Web Server 7.0 Update 2 release.
This change does
not manifest while using Web Server 7.0 Update 2 RPP.
A modification
in the Web Server's request processing engine to fix a significant error in
Web Server, has changed the order in which the web server processes objects
and directives in the server's obj.conf file. This correction
now guarantees that the below rules are applied while processing a request:
-
All ppath objects that apply to a request are
evaluated
-
If there is a named object that applies to a request, it will
take precedence over any ppath objects in cases where the two conflict.
If your obj.conf file contain ppath objects,
evaluate them to determine if your obj.conf file requires any modification.
As a consequence of the above change in the request processing behavior,
when you upgrade previous Web Server versions to the Web Server 7.0 Update
2, or later, you may have to make minor changes to the obj.conf files, as listed
below:
-
Using IF directive
In the following example, directives contained in the ppath objects will
not be invoked when an explicit JSP extension is found in the request URI,
as the ntrans-j2ee NameTrans
SAF will apply to a JSP extension and cause the object named j2ee to be evaluated
next. The WebLogic proxy service used here to forward requests to the WebLogic
server is no longer invoked, although there are no modifications made to the obj.conf file. As a result,
the web server sends the request to it's own web container, instead of the
WebLogic proxy, resulting in failure of the request.
In the obj.conf file, default
object, add a conditional statement to the ntrans-j2ee service with
the problem URIs, as shown below:
<Object name="default">
AuthTrans fn="match-browser" browser="*MSIE*" ssl-unclean-shutdown="true"
#
#Adding <IF...> and </IF> bracketing to compensate
for change in ppath processing
#
<IF $uri !~ ".*WebApp/.*" >
NameTrans fn="ntrans-j2ee" name="j2ee"
PathCheck fn="find-index-j2ee"
ObjectType fn="type-j2ee"
Error fn="error-j2ee"
</IF>
|
....
....
<Object name="j2ee">
Service fn="service-j2ee" method="*"
</Object>
<Object ppath="*/examplesWebApp/*" >
Service fn=wl_proxy WebLogicHost=jwsse10.red.iplanet.com WebLogicPort=7001
</Object>
<Object ppath="*/ejemploWebApp/*">
Service fn=wl_proxy WebLogicHost=jwsse10.red.iplanet.com
WebLogicPort=7002
</Object>
</Object>
|
This allows the ntrans-j2ee to be executed only when the URI's do not match.
-
Using assign-name NameTrans
In simple scenarios, you can
change ppath objects to name objects by using assign-name in the default object. This allows the assign-name to be executed
ahead of ntrans-j2ee.
<Object name="default">
NameTrans fn="assign-name" from="/examplesWebApp/*" name="examples_proxy"
NameTrans fn="assign-name" from="/ejemploWebApp/*" name="ejemplo_proxy"
NameTrans fn="ntrans~j2ee" name="j2ee"
....
....
</Object>
<Object name="j2ee">
Service fn="service-j2ee" method="*"
</Object>
<Object name="examples proxy" >
Service fn=wl_proxy WebLogicHost=jwsse10.red.iplanet.com WebLogicPort=7001
</Object>
<Object name="ejemplo proxy">
Service fn=wl_proxy WebLogicHost=jwsse10.red.iplanet.com WebLogicPort=7002
</Object>
|
-
Disabling
Turning
off Java Web container support on web server will ensure that the JSPs will
be handled by WebLogic proxy function. However, this is only suggested when
you do not intend to host Java content in the proxying tier.
|