|
|
|
|
|
|
| | | |
FAQs: Security
How can I update my demonstration digital certificates and trusted CAs?
When the demonstration certificates expire or when you want to go into Production, BEA recommends purchasing your own certificates and trusted CAs from a reputable vendor such as Verisign or Entrust. To purchase your own certificates, you can generate a certificate signature request (CSR) using the Certificate Request servlet described in Managing Security. Once you get new certificates and trusted CAs, you need to delete the files for the demonstration digital certificates and trusted CA and replace them with the new ones. You also have to reset the SSL attributes in the Administration Console.
Why does the servlet return "no certificate"?
You may receive this message when you try to use the certificate capture facility to provide two-way authentication. To troubleshoot, please check the following:
Does WebLogic support Diffie-Hellman or DSS/DSA digital certificates?
No. The exportable version of WebLogic supports only 512 bit RSA with 40 bit RC4. Additionally, browsers do not support these types of certificates, and there are no commercial issuers for DSA certificates.
Can the server have one RSA and one non-RSA certificate?
Must we pay RSA licensing costs for non-RSA client code?
WebLogic has licensed RSA for SSL between WebLogic Servers and clients. With WebLogic, no extra licensing for RSA is necessary, although different rules apply to VARs.
How do I use Netscape security certificates with WebLogic Server?
Netscape stores the private and public keys together in a key-pair file, which prevents you from separating the public and private keys. In config.xml, the ServerKeyFileName attribute refers only to the private key file. Therefore, you must generate another request for a certificate, not using Netscape utilities. You can use the Certificate Request servlet to generate a request for a new certificate. Using WebLogic SSL shows how to use the servlet.
How do I restrict access to servlets and JSPs?
The Java Servlet API Specification v2.2 allows you to declaratively restrict access to specific Servlets and JSPs using the Web Application Deployment descriptor. Section 13.3.2 of the specification has an example deployment descriptor that uses declarative security. For more information, see Programming WebLogic HTTP Servlets.
Can I use RSA encryption algorithms and javax.crypto.* API to build applications?
No. WebLogic's RSA license does not permit end-users to use RSA classes directly. You must obtain your own license for the encryption libraries from RSA.
Can I use a JNDI Initial Context to pass the security credentials of a WebLogic Server user?
Yes, but not in releases that come after 6.1. In releases that come after 6.1, you must use the Java Authentication and Authorization Service (JAAS) rather than JNDI to associate a User with a security context. For more information, see Programming WebLogic Security.
Why can't I boot WebLogic Server when using the LDAP Security Realm?
When using an alternative security realm or a custom security realm in WebLogic Server, you must configure and enable the Caching realm.
When the LDAP server in Microsoft Site Server is installed and the root of the LDAP directory is created, a number of organizational units are created by default. Under Groups there is a default organization unit called NTGroups with a default group called Administrators which is empty. By default, WebLogic Server also provides a Group called Administrators that contains a member System which is the User under which WebLogic Server is started. If you use the defaults in Microsoft Site Server and start creating your own Groups under the default organizational units, WebLogic Server will not start. You need to create your own organizational unit in the LDAP directory and create your Groups under that organizational unit.
If you have two Groups in the LDAP directory with the same name, WebLogic Server cannot properly authenticate the Users in the Groups. The LDAP security realm uses the Group's DN (distinguished name) to locate Groups in the LDAP directory. If you create more than one group with the same name, WebLogic Server only authenticates the Users in the first Group it locates. You must use unique Group names when using the LDAP security realm.
The LDAP realm V2 does not provide the following functionality provided in the LDAP realm V1:
The LDAP security realm needs to know where the Users and Groups are stored in the LDAP directory used with the security realm. This is done by specifying the distinguished names (DNs) of the LDAP directories containing the Users and Groups.
In LDAP, a DN starts with the leaf node and goes to the root node. The following figure shows a branch of a LDAP directory.
root | | o=acme.com | | ou=Groups
The DN for this branch would be specified as ou=Groups, o=acme.com.
In LDAP realm V1, you specify DNs via the GroupDN and UserDN attributes on the LDAPRealm MBean or through the Administration Console. However, you must reverse the DNs so the example DN would be specified as:
groupDN="o=acme.com, ou=Groups"
In LDAP realm V2, you specify DNs by adding user.dn and group.dn properties to the Configuration attribute of the CustomRealm MBean or through the Administration Console. Unlike LDAP realm V1, you do not have to reverse the DN. For example, the user.dn and group.dn properties for a LDAP realm V2 are specified as follows:
ConfigurationData="..., group.dn=ou=Groups, o=acme.com,..."
In short, the LDAP realm V1 requires reverse DNs and the LDAP realm V2 requires normal DNs.
A common error customers make when switching between LDAP realm V1 and LDAP realm V2 is copying over the reverse DNs thus causing the LDAP realm to stop working. Check your DN specifications when migrating from LDAP realm V1 to LDAP realm V2.
Are WebLogic Server passwords secure?
The config.xml file no longer has clear text passwords. In place of clear text passwords, the config.xml file has encrypted, hashed passwords. You cannot copy encrypted passwords from one domain to another. Instead, you can edit the config.xml file and replace the existing encrypted, hashed passwords with clear text passwords and then copy the file to the new domain. The Administration Console will encrypt and hash the passwords the next time it writes to the file.
The RecordingSecurityManager utility can be used to detect permission problems that occur when starting and running WebLogic Server. The utility outputs permissions that can be added to your config.xml or Java security policy file to resolve the permission problems that the utility finds. The RecordingSecurityManager utility is available from dev2dev Online.
Why do I get this error <Alert> <WebLogicServer> <Security> configuration problem with certificate file when I start my server?
It is possible that you did not specify a "WL_HOME" relative file name in your SSL configuration files. For more information about WL_HOME, see Configuring the SSL Protocol under Managing Security in the Administration Guide
Why can't I establish an outbound SSL connection when using the demonstration certificates?
When establishing an SSL connection, the subject DN of the digital certificate must match the host name of the server initiating the SSL connection. Otherwise, the SSL connection is dropped. If you use the demonstration certificates, the host names will not match. To avoid this situation, use the -Dweblogic.security.SSL.ignoreHostnameVerification=true flag when starting WebLogic Server. This flag disables the Host Name Verifier which compares the subject DNs and host names. This solution is recommended in development environments only. A more secure solution is to obtain a new digital certificate for the server making outbound SSL connections.
Why do I get the error, <WebLogic Server> <SSLListenThread listening on port 8802> Failed to connect to t3s://localhost:8802, when establishing an SSL connection to WebLogic Server?
By default, WebLogic Server contains a Host Name Verifier that compares the subject DNs of digital certificates and host names. When establishing an SSL connection, the subject DN of the digital certificate must match the host name of the server initiating the SSL connection. If you use the demonstration certificates the host names will not match. To avoid this situation, use the -Dweblogic.security.SSL.ignoreHostnameVerification=true flag when starting WebLogic Server. This flag disables the Host Name Verifier. This solution is recommended in development environments only. A more secure solution is to obtain a new digital certificate for your WebLogic client.
How do I protect WebLogic Server from security attacks from bogus clients using the WL-Proxy-Client-Cert header?
The WL-Proxy-Client-Cert header can be spoofed (used) by any client which has direct access to WebLogic Server. WebLogic Server takes the certificate information from that header, trusting that is came from a secure source (the plug-in) and use that information to authenticate the user. In previous releases of WebLogic Server, the default behavior was to always trust that header. Now you need to explicitly define trust of the WL-Proxy-Client-Cert header. A new parameter clientCertProxy allows WebLogic Server to on the implicit trust of the certificate header. If you need an additional level of security, use a connection filter to limit all connections into WebLogic Server (therefore allowing WebLogic Server to only accept connections from the machine on which the plug-in is running).
The clientCertProxy parameter has been added to the HTTPClusterServlet and Web applications.
For the HTTPClusterServlet, add the parameter to the web.xml file as follows:
<context-param>
<param-name>clientCertProxy</param-name>
<param-value>true</param-value>
</context-param>
For Web applications, add the parameter to the web.xml file as follows:
ServletRequestImpl context-param
<context-param>
<param-name>weblogic.http.clientCertProxy</param-name>
<param-value>true</param-value>
</context-param>
You can also use this parameter in a cluster as follows:
<Cluster ClusterAddress="127.0.0.1" Name="MyCluster"
ClientCertProxyHeader="true"/>
|
|
|
|
|
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|