[Fedora-directory-users] Sudo in directory server
by Erling Ringen Elvsrud
I try to add the schema for sudoers from README.LDAP in
the srpm-file of sudo-1.6.8p12. I assume the iPlanet-version will work best, but
get this problem when I restart directory server:
[root@testserver schema]# service dirsrv restart
Shutting down dirsrv:
testserver... [ OK ]
Starting dirsrv:
testserver...[27/Nov/2008:10:37:31 +0100] - Entry "cn=schema
attributeTypes: ( 1.3.6.1.4.1.15953.9.1.1 NAME 'sudoUser' DESC
'User(s) who may run sudo' EQUALITY caseExactIA5Match SUBSTR caseE"
required attribute "objectclass" missing
[ OK ]
[root@testserver schema]# cat 99sudoers.ldif
dn: cn=schema attributeTypes: ( 1.3.6.1.4.1.15953.9.1.1 NAME
'sudoUser' DESC 'User(s) who may run sudo' EQUALITY caseExactIA5Match
SUBSTR caseE
xactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'SUDO' )
attributeTypes: ( 1.3.6.1.4.1.15953.9.1.2 NAME 'sudoHost' DESC
'Host(s) who may run sudo' EQUALITY caseExactIA5Match SUBSTR caseEx
actIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'SUDO' )
attributeTypes: ( 1.3.6.1.4.1.15953.9.1.3 NAME 'sudoCommand' DESC
'Command(s) to be executed by sudo' EQUALITY caseExactIA5Match S
YNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'SUDO' )
attributeTypes: ( 1.3.6.1.4.1.15953.9.1.4 NAME 'sudoRunAs' DESC
'User(s) impersonated by sudo' EQUALITY caseExactIA5Match SYNTAX 1
.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'SUDO' )
attributeTypes: ( 1.3.6.1.4.1.15953.9.1.5 NAME 'sudoOption' DESC
'Options(s) followed by sudo' EQUALITY caseExactIA5Match SYNTAX 1
.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'SUDO' )
objectClasses: ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' SUP top
STRUCTURAL DESC 'Sudoer Entries' MUST ( cn ) MAY ( sudoUser $ sud
oHost $ sudoCommand $ sudoRunAs $ sudoOption $ description ) X-ORIGIN 'SUDO' )
Any help to get the schema for sudo correctly added is appreciated.
Thanks,
Erling
14 years, 8 months
[Fedora-directory-users] Ubuntu not enforcing password policies
by John A. Sullivan III
Hello, all. We're continuing to dive ever deeper into DS. Our thanks
to the developers for such a powerful product.
Our integration with the RedHat family has gone well but now we're
working on Ubuntu. Most is working well but we are finding Ubuntu is
not enforcing password policies. For example, we require a user to
change their password after a reset. When a user logs into a RedHat
system, they are prompted for the change. However, Ubuntu just lets
them right in again and again with the same reset password.
Any pointers on what to look for to fix this in our configuration before
we scour the world for a solution? We've already done quite a bit of
googling.
We've tried enabling pam_lookup_policy but that didn't
work. /etc/pam.d/common-password reads:
password requisite pam_cracklib.so retry=3 minlen=8 difok=3
password [success=2 default=ignore] pam_unix.so obscure use_authtok try_first_pass sha512
password [success=1 user_unknown=ignore default=die] pam_ldap.so use_authtok try_first_pass
# here's the fallback if no module succeeds
password requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
password required pam_permit.so
We've also tried disabling that last pam_permit.so. That didn't help. Where should we look? Thanks - John
--
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan(a)opensourcedevel.com
http://www.spiritualoutreach.com
Making Christianity intelligible to secular society
14 years, 9 months
[Fedora-directory-users] DSGW problem - browser user tries to change password
by John A. Sullivan III
Hello, all. As explained in the last email, we do not allow anonymous
browsing but have a specific user with limited rights browsing the tree
to find users' identities for logging into DSGW. We also have a policy
that users must change their passwords after a reset.
We have a test user sue.sutter. We reset her password and then had her
attempt to login to DSGW. Sure enough, she was told she needed to
changed her password and was given the option to do so. However, the
attempt failed with the below error messages:
Editing sue.sutter...
Sending changes to the directory server...
An error occurred while contacting the LDAP server.
(Insufficient access - Insufficient 'write' privilege to the
'userPassword' attribute of entry
'uid=sue.sutter,ou=users,o=a0000-0006,o=internal,dc=ssiservices,dc=biz'. )
You do not have sufficient privileges to perform the operation.
That seemed very strange because when we test changing passwords using
her posix account, it works just fine. We then gave the browsing user
(not sue.sutter) full rights to the tree and, lo and behold, it worked:
Giving the directory browser user all rights allowed a successful
password change.
It appears the browsing user is the one attempting to change the user's
password and not the user. Is that the way it's supposed to be? I
certainly would not want a browse only utility user able to change user
passwords. Perhaps I am missing something. Thanks - John
--
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan(a)opensourcedevel.com
http://www.spiritualoutreach.com
Making Christianity intelligible to secular society
14 years, 9 months
[Fedora-directory-users] Many DSGW authentication problems
by John A. Sullivan III
I'm finding several weird issues with DSGW authentication which make it
very difficult for our users to use. Not to complain - great DS - but
we're experiencing some problems.
We do not allow anonymous browsing of the tree. Each client has a user
who has rights to search only their portion of the tree for possible
DSGW logins. The ACI, place on the root, is thus:
(target =
"ldap:///ou=Users,($dn),o=Internal,dc=ssiservices,dc=biz")(targetattr =
"uid || st || sn || ou || name || entrydn || dn || dc || objectClass ||
cn || o || l || c || givenName") (version 3.0;acl "Client DSGW
Lister";allow (search,read)(userdn =
"ldap:///uid=*dsgwlister,[$dn],o=sysaccounts,dc=ssiservices,dc=biz");)
We have an example test user named sue.sutter. The full dn is
uid=sue.sutter,ou=users,o=a0000-0006,o=internal,dc=ssiservices,dc=biz
The first step is to go the authentication page where we read:
"The first step in authenticating to the directory is identifying
yourself."
This is why we created a user with rights to browse for other users and
defined it with a binddnfile entry. That part is working fine.
If I enter sue.sutter, it does not find her directly but rather offers a
list with a single hyperlinked choice. That's the first problem (a
problem for anyone with a "." in their uid). The query has replaced the
"." with a space:
filter="(&(objectClass=person)(|(sn=sue sutter)(cn=sue sutter)))
I tried surrounding it with quotes and escaping it with a back slash but
the quote was interpreted literally and the back slash gave the same
results as the period alone.
Is this a bug, a configuration error, or just the way it's supposed to
be? If the latter, this is very user unfriendly. A techie might
understand escape characters or special encoding but not an everyday
user.
It wouldn't be so bad if they could simply click on the hyperlink and be
allowed to login. However, the hyperlink does not work. Mousing over
gives:
javascript:authSubmit('uid%3Dsue.sutter%2Cou%3DUsers%2Co%3Da0000-0006%
2Co%3DInternal%2Cdc%3Dssiservices%2Cdc%3Dbiz');%20onMouseOver=
but it goes nowhere. A packet trace shows no packets coming from the
browser to the DS. What might we have configured incorrectly to cause
this? We see the same thing in Konqueror as we see in Firefox3 all
running on fully patched Ubuntu 8.0.4.
Hmmm . . . this is getting long. I'll put the other problem into
another email. Thanks - John
--
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan(a)opensourcedevel.com
http://www.spiritualoutreach.com
Making Christianity intelligible to secular society
14 years, 9 months
[Fedora-directory-users] Re: fedora ds migration error
by Eric
there is /var/run/dirsrv on my system and there is dsgw/cookies in it.
why server fails to start?
Date: Wed, 26 Nov 2008 08:25:31 -0700
From: Rich Megginson <rmeggins(a)redhat.com>
Subject: Re: [Fedora-directory-users] Re: error in yum fedora-ds
To: "General discussion list for the Fedora Directory server project."
<fedora-directory-users(a)redhat.com>
Message-ID: <492D6A6B.2080802(a)redhat.com>
Content-Type: text/plain; charset="iso-8859-1"
Eric wrote:
> I used :rpm --import
> 'http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA7B02652'
> <http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA7B02652%27>
> and the problem solved. I installed fedora-ds then used
> /usr/sbin/migrate-ds-admin.pl for migration from fedora ds-1.0.4.
> I stoped slapd-instance before this. it faild in start server:
mkdir /var/run/dirsrv
make sure that directory is writable by your directory server user
>
> /usr/sbin/migrate-ds-admin.pl General.ConfigDirectoryAdminPwd=mypassword
> Beginning migration of Directory and Administration servers from
> /opt/fedora-ds . . .
> Beginning migration of directory server instances in /opt/fedora-ds . . .
> Your new DS instance 'slapd-ldap' was successfully created.
> Server failed to start !!! Please check errors log for problems
> Beginning migration of Administration server from /opt/fedora-ds . . .
> Creating Admin Server files and directories . . .
> Updating the configuration for the httpd engine . . .
> Starting admin server . . .
> The admin server was successfully started.
> Registering the directory server instances with the configuration
> directory server . . .
> Directory and Administration servers migration is complete. Please
> check output and log files for details.
> Exiting . . .
>
> what is wrong? now the slapd in /opt/fedora-ds doesn't work too!
14 years, 10 months
[Fedora-directory-users] fedora-idm-console error
by Eric
Hi,
I have migrated from fedora-ds 1.0.4 on the same system. when I stoped admin
and slapd in /opt/fedora-ds.
in starting fedora-idm-console I use the port that I had from installing
fedora-ds 1.0.4.
it has this error:
cannot connect to the directory server netscape.ldap.LDAPException:error
result(32); no such object.
14 years, 10 months
[Fedora-directory-users] Command line created posix user shows posix disabled in console
by John A. Sullivan III
I've created a bash script to add ds entries for new clients as we bring
them on board. It automatically creates their user accounts which
include the posixaccount object class (as well as account (to allow the
host attribute) and posixgroup (to allow gidnumber for personal
groups)).
They appear to be created fine. Users can login, change passwords, etc.
However, when I view the user in the idm-console, the posix attributes
are present but the enable checkbox is unchecked and the attributes are
greyed out and uneditable.
If I click the enable check box, the fields are enabled but when I
attempt to save the change I get an error:
Cannot save to directory server:
netscape.ldap.LDAPException: error result(1): Operations error
I would not doubt this is because it's trying to add a posixaccount
value to objectclass when one already exists. In any event, if I enable
posix and change an attribute, I get the same error. However, if I go
to the advanced page instead, and change a posix attribute there, the
change saves perfectly fine.
Any idea what is happening and what I've done wrong? In case more
information is needed, here are some of the gory details.
There are attribute uniqueness constraints. uidnumber and gidnumber are
globally unique. uid and cn are unique within an ou within an o -
fairly granular. I did try disabling the global constraints but to no
avail.
By the way, those users with NT attributes show up fine with the NT User
enabled check box checked.
Here is a typical LDIF entry:
dn: uid=userx,ou=Users,ou=Internal,o=a0000-0002,dc=ssiservices,dc=biz
changetype: add
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: posixaccount
objectclass: account
objectclass: posixgroup
uid: userx
cn: userx
userpassword: ea4cb9eedc
uidnumber: 2001
gidnumber: 2001
homedirectory: /data/users/userx
loginshell: /bin/sh
givenname: John A.
sn: Sullivan III
mail: userx(a)somecompany.biz
telephonenumber: +1 (207) 999-9999
I can't imagine it is significant but, just in case, here is the LDIF creation from the script:
The input syntax is:
uid|givenname|sn|emailuser(no domain)|phone|location|W|"|" delimited attribute=value pairs
UIDNUMBERS[$counter]=${CIDU}
PWS=$(echo ${CIDU}${FIRST} | md5sum)
PWS=${PWS:0:10}
echo -e "${FIRST} ${PWS}\n\n" >> ${CID}.temp
TEMPS="dn: uid=${FIRST},${USUFFIX}\n${ADDPERSON}uid: ${FIRST}\ncn: ${FIRST}\nuserpassword: ${PWS}\nuidnumber: ${CIDU}\ngidnumber: ${CIDU}\nhomedirectory: /data/users/${FIRST}\nloginshell: /bin/sh\n"
c=0
for var in ${REST}
do
if [ -n "${var}" ]; then
case ${c} in
0)
TEMPS="${TEMPS}givenname: ${var}\n";;
1)
TEMPS="${TEMPS}sn: ${var}\n";;
2)
TEMPS="${TEMPS}mail: ${var}${EDOMAIN}\n";;
3)
TEMPS="${TEMPS}telephonenumber: ${var}\n";;
4)
TEMPS="${TEMPS}physicaldeliveryofficename: ${var}\n";;
5)
TEMPS="${TEMPS}${ADDWIN}ntuserdomainid: ${FIRST}\nntusercreatenewaccount: true\nntuserdeleteaccount: true\n";;
*)
var=${var/=/: }
TEMPS="${TEMPS}${var}\n";;
esac
fi
((c = c + 1))
done
TEMPS="${TEMPS}\n"
echo -e ${TEMPS} >> ${LDIF}
((counter = counter + 1))
((CIDU = CIDU + 1))
Here are some of the variable definitions:
BASE="dc=ssiservices,dc=biz"
NEWO="o=${CID},${BASE}"
SYSACCOUNTS="ou=SysAccounts,${NEWO}"
USUFFIX="ou=Users,ou=Internal,${NEWO}"
ADDS="changetype: add\n"
TOPS="${ADDS}objectclass: top\n"
ADDO="${TOPS}objectclass: organization\n"
ADDOU="${TOPS}objectclass: organizationalUnit\n"
ADDSYSPERSON="${TOPS}objectclass: person\nobjectclass: organizationalPerson\nobjectclass: inetOrgPerson\n"
ADDPERSON="${ADDSYSPERSON}objectclass: posixaccount\nobjectclass: account\nobjectclass: posixgroup\n"
ADDGROUP="${TOPS}objectclass: groupofuniquenames\nobjectclass: posixgroup\n"
ADDWIN="objectclass: ntuser\n"
What is going on? Thanks - John
--
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan(a)opensourcedevel.com
http://www.spiritualoutreach.com
Making Christianity intelligible to secular society
14 years, 10 months
[Fedora-directory-users] mod_nss OCSP failover to CRL
by sg4all
Hi,
I'm trying to set up a apache webserver with mod_nss. When available, OCSP
should be used to verify the validity of the certificate. When the OCSP is
unavailable, CRLs are used.
I installed the CRLS, and configured everything. (My nss.conf is included in
this message).
When I comment out "NSSOCSP On": it validates the certificates using CRL
correctly.
When "NSSOCSP on" is used, it validates the certificates using OCSP
correctly.
However, when NSSOCSP is enabled, but I make the OCSP server unavailable
(e.g. by putting an extra entry in /etc/hosts), a request takes a long time
(I guess mod_nss tries a few times to get to the OCSP) and eventually fails.
Is what I want supported? If so, does anyone have a clue what I do wrong?
I tried this on CentOS5. I tried this configuration file on 2 versions of
mod_nss. First using version 1.0.3-4.el5 which is installed using 'yum
install mod_nss'. I also tried it on version 1.0.8 (which I built from
source)
thanks!
My nss.conf file:
#
# This is the Apache server configuration file providing SSL support using.
# the mod_nss plugin. It contains the configuration directives to instruct
# the server how to serve pages over an https connection.
#
# Do NOT simply read the instructions in here without understanding
# what they do. They're here only as hints or reminders. If you are unsure
# consult the online docs. You have been warned.
#
LoadModule nss_module modules/libmodnss.so
#
# When we also provide SSL we have to listen to the
# standard HTTP port (see above) and to the HTTPS port
#
# Note: Configurations that use IPv6 but not IPv4-mapped addresses need two
# Listen directives: "Listen [::]:443" and "Listen 0.0.0.0:443"
#
Listen 443
##
## SSL Global Context
##
## All SSL configuration in this context applies both to
## the main server and all SSL-enabled virtual hosts.
##
#
# Some MIME-types for downloading Certificates and CRLs
#
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl .crl
# Pass Phrase Dialog:
# Configure the pass phrase gathering process.
# The filtering dialog program (`builtin' is a internal
# terminal dialog) has to provide the pass phrase on stdout.
NSSPassPhraseDialog builtin
# Pass Phrase Helper:
# This helper program stores the token password pins between
# restarts of Apache.
NSSPassPhraseHelper /usr/sbin/nss_pcache
# Configure the SSL Session Cache.
# NSSSessionCacheSize is the number of entries in the cache.
# NSSSessionCacheTimeout is the SSL2 session timeout (in seconds).
# NSSSession3CacheTimeout is the SSL3/TLS session timeout (in seconds).
NSSSessionCacheSize 10000
NSSSessionCacheTimeout 100
NSSSession3CacheTimeout 86400
#
# Pseudo Random Number Generator (PRNG):
# Configure one or more sources to seed the PRNG of the SSL library.
# The seed data should be of good random quality.
# WARNING! On some platforms /dev/random blocks if not enough entropy
# is available. Those platforms usually also provide a non-blocking
# device, /dev/urandom, which may be used instead.
#
# This does not support seeding the RNG with each connection.
NSSRandomSeed startup builtin
#NSSRandomSeed startup file:/dev/random 512
#NSSRandomSeed startup file:/dev/urandom 512
##
## SSL Virtual Host Context
##
<VirtualHost _default_:443>
# General setup for the virtual host
#DocumentRoot "/etc/httpd/htdocs"
#ServerName www.example.com:443
#ServerAdmin you(a)example.com
# Use separate log files for the SSL virtual host; note that LogLevel
# is not inherited from httpd.conf.
#ErrorLog /etc/httpd/logs/nss_error_log
#TransferLog /etc/httpd/logs/nss_access_log
LogLevel debug
# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
NSSEngine on
# SSL Cipher Suite:
# List the ciphers that the client is permitted to negotiate.
# See the mod_nss documentation for a complete list.
# SSL 3 ciphers. SSL 2 is disabled by default.
NSSCipherSuite
+rsa_rc4_128_md5,+rsa_rc4_128_sha,+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha
#NSSCipherSuite -ALL:SSLv3+HIGH:-aNULL
# SSL 3 ciphers + ECC ciphers. SSL 2 is disabled by default.
#
# Comment out the NSSCipherSuite line above and use the one below if you
have
# ECC enabled NSS and mod_nss and want to use Elliptical Curve Cryptography
#NSSCipherSuite
+rsa_rc4_128_md5,+rsa_rc4_128_sha,+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha,-ecdh_ecdsa_null_sha,+ecdh_ecdsa_rc4_128_sha,+ecdh_ecdsa_3des_sha,+ecdh_ecdsa_aes_128_sha,+ecdh_ecdsa_aes_256_sha,-ecdhe_ecdsa_null_sha,+ecdhe_ecdsa_rc4_128_sha,+ecdhe_ecdsa_3des_sha,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_sha,-ecdh_rsa_null_sha,+ecdh_rsa_128_sha,+ecdh_rsa_3des_sha,+ecdh_rsa_aes_128_sha,+ecdh_rsa_aes_256_sha,-echde_rsa_null,+ecdhe_rsa_rc4_128_sha,+ecdhe_rsa_3des_sha,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_sha
#NSSProtocol SSLv3,TLSv1
NSSProtocol -ALL +SSLv3 +TLSv1
# SSL Certificate Nickname:
# The nickname of the RSA server certificate you are going to use.
NSSNickname Server-Cert
# SSL Certificate Nickname:
# The nickname of the ECC server certificate you are going to use, if you
# have an ECC-enabled version of NSS and mod_nss
#NSSECCNickname Server-Cert-ecc
# Server Certificate Database:
# The NSS security database directory that holds the certificates and
# keys. The database consists of 3 files: cert8.db, key3.db and secmod.db.
# Provide the directory that these files exist.
NSSCertificateDatabase /etc/httpd/alias
# Database Prefix:
# In order to be able to store multiple NSS databases in one directory
# they need unique names. This option sets the database prefix used for
# cert8.db and key3.db.
#NSSDBPrefix my-prefix-
# Client Authentication (Type):
# Client certificate verification type. Types are none, optional and
# require.
NSSVerifyClient require
#
# Online Certificate Status Protocol (OCSP).
# Verify that certificates have not been revoked before accepting them.
NSSOCSP On
# Access Control:
# With SSLRequire you can do per-directory access control based
# on arbitrary complex boolean expressions containing server
# variable checks and other lookup directives. The syntax is a
# mixture between C and Perl. See the mod_nss documentation
# for more details.
#<Location />
#NSSRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \
# and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
# and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \
# and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \
# and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \
# or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/
#</Location>
# SSL Engine Options:
# Set various options for the SSL engine.
# o FakeBasicAuth:
# Translate the client X.509 into a Basic Authorisation. This means
that
# the standard Auth/DBMAuth methods can be used for access control. The
# user name is the `one line' version of the client's X.509 certificate.
# Note that no password is obtained from the user. Every entry in the
user
# file needs this password: `xxj31ZMTZzkVA'.
# o ExportCertData:
# This exports two additional environment variables: SSL_CLIENT_CERT and
# SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
# server (always existing) and the client (only existing when client
# authentication is used). This can be used to import the certificates
# into CGI scripts.
# o StdEnvVars:
# This exports the standard SSL/TLS related `SSL_*' environment
variables.
# Per default this exportation is switched off for performance reasons,
# because the extraction step is an expensive operation and is usually
# useless for serving static content. So one usually enables the
# exportation for CGI and SSI requests only.
# o StrictRequire:
# This denies access when "NSSRequireSSL" or "NSSRequire" applied even
# under a "Satisfy any" situation, i.e. when it applies access is denied
# and no other module can change it.
# o OptRenegotiate:
# This enables optimized SSL connection renegotiation handling when SSL
# directives are used in per-directory context.
NSSOptions +FakeBasicAuth +ExportCertData +StrictRequire
##<Files ~ "\.(cgi|shtml|phtml|php3?)$">
# NSSOptions +StdEnvVars
#</Files>
#<Directory "/var/www/cgi-bin">
# NSSOptions +StdEnvVars
#</Directory>
# Per-Server Logging:
# The home of a custom SSL log file. Use this when you want a
# compact non-error SSL logfile on a virtual host basis.
#CustomLog /home/rcrit/redhat/apache/logs/ssl_request_log \
# "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>
<Location "/">
NSSRequireSSL
</Location>
14 years, 10 months
