LINUX distribution

The configurations were tested on the following environment, for others check working path, and available tested release.
See our best practices to install services and keep them up to date.

fedora-release-6-4 

httpd-2.2.3-5

openssl-0.9.8b-8
selinux-policy-targeted-2.4.6-1.fc6 

fedora-release-5-5  

httpd-2.2.0-5.1.2

openssl-0.9.8a-5.4
selinux-policy-targeted-2.3.7-2.fc5

PERMISSIONS

Check file permissions on path /etc/httpd

Handy Hint It is wise tu run httpd in a chroot environment. It is out of the scope of this document to describe how. But keep in mind that when you copy (or mount --bind) your directories and files, you should keep permissions and SELinux context. The recommended chroot path for httpd is "/var/httpd/chroot"

SELINUX context

See our best practices to keep correct file paths and remember that SELinux context is inherited from the directory level. It means that if you change a default directory, you should check the context of the newly created one.

Check files context on path /etc/httpd

Check files context on path /etc/pki/tls

JAVA environement

How to enable SSL in a JAVA environment is presented in a separate document. Meanwhile it's common that JAVA application (i.e: Tomcat) delegates SSL handling to httpd

Others security features

Be Careful Remember that with certificates, acceptance is controlled by the Certification authorities (CA) certificates you store in your CA path (i.e: /etc/pki/tls/certs). A default bundle file of CA certs is located at "/etc/pki/tls/certs/ca-bundle.crt". Also remember that if your host private key is stolen, one can impersonate your host over the internet. Especially if you use all purposes certificates.

Enabling SSL

You need to attach certificates and related stuff to the httpd service. That is you have to perform the following steps:

1. Obtain a certificate for your host
   • Check the DNS naming scheme of your hosts and services
   • Adopt an external naming scheme, or define one for your OSI names osiNames
   • Check your host name, it defaults to your FQDN (ie:host.example.com)hostname
     • Configure virtual host name if desired virtualHostname
     • Update DNS or DNSSEC accordingly
   • Prepare a PKCS10 certificate request or go to an online certification enrollment
     • Choose between self signed certificates or certificates from an external CA
     • Use openssl command line opensslCli or CA web form
     • Always enter your FQDN host name as CN (Common name) ie:host.example.com fillingDN
     • Check that you request a certificate for client and server authentication purposes certsPurpose
   • Retrieve your signed certificate certRetrieve
     • Check it is in PEM format (base 64 encoded) and convert it if necessary
     • Verify your certificate purpose certVerify
     • check the content of your signed certificate certCheck
   • Get your associated certificate key keyRetrieve
2. Retrieve the Certification Authority certificate(s)CAcertsRetrieve
3. Retrieve the Certification Authority CRL (certificate revocation list) CRLcertsRetrieve
4. Update your certificates repository
   • copy your private key in /etc/pki/tls/private
   • copy your public key in /etc/pki/tls/certs
   • copy the CA public key in /etc/pki/tls/certs
   • update certificate repository with CRLs in /etc/pki/tls/crls CRLcertsStore
   • Setup a cron job to retrieve regularly updated CRLs CRLcertsCron
   • Decide if you want to keep default Certification authorities bundled file certsBundle
5. Choose your SSL port (default: Listen 443) portSSL
   • Attach a virtual server to the SSL port (default: <VirtualHost default:443>)
6. update /etc/httpd/conf.d/ssl.conf
   • SSLCertificateFile /etc/pki/tls/certs/virtual-host.crt
   • SSLCertificateKeyFile /etc/pki/tls/private/virtual-host.key
   • SSLCertificateChainFile /etc/pki/tls/certs/ca-bundle.crt
   • SSLCACertificateFile /etc/pki/tls/certs/cacert.pem
   • SSLCARevocationPath /etc/pki/tls/crls
7. Check your apache http configuration (command: apachectl configtest)
8. Start or restart httpd (command: service httpd restart)
9. Check log files for errors (command: tail /var/log/httpd/error_log)
10. Check for proper SSL activation (with https: // virtual-host.example.com)
    
    

    ---

    Return to top of page topSSL
    

    Adopt an external naming scheme, or define one for your OSI names

    OSI stands for "Open Standards for Interconnection" from ISO / ITU
    an OSI name is called a "Distinguished name" which is used in all OSI related technologies such as

• Certificates (X509)
• LDAP directories including Microsoft Active directory (X500)
• Military and aeronautical messaging systems (X400)

A "Distinguished name" (DN) is a collection of one or more of the following components

• CN Common name
• OU Organisation Unit
• O Organization
• C Country
• and many others like "gn givenname","sn surname","l location" ......

Example DN
DN: cn=My_full_FQDN_name,ou=Related_Organisation_Unit,ou=other_related_unit,o=Company_name,c=country

or with the alternate DC scheme mostly used in directories.

DN:cn=My_full_FQDN_name,ou=Related_Organisation_Unit,ou=other_related_unit,dc=example,c=com

Common meanings of OU are as follows:

• OU=Hosts
• OU=People # users
• OU=Services # Daemons

openOSI also uses in its naming scheme:

• OU=VirtualHosts
• OU=VirtualPeople # nicknames
• OU=PKI # Certification authorities

In principle you are free to use what you want as DN components value, unless you request a certification authority to certify these values. That is unless you intend a public use of these names to participate in an Internet of trust (similarly to the dns - Domain name system).

You MUST use a "Distinguished name" to generate a certificate request, see fillingDN

For additional information check the various OSI X500 and RFC

Useful Information There could be links between DNS and OSI naming scheme, especially when domain components are used for distinguished names. Some people stores DNS DB in an LDAP directory (like Microsoft optionally). Most people don't in order to keep loosely coupling between DNS and Directories. There is an interesting use of LDAP directories for certificates when storing these certificates and their revocation list (CRL) in the directories. Therefore you MAY imagine a scheme that facilitate directory searching for your certificate retrieval. That is unless you use a third part directory like openOSI (directory.opensosi.org). openOSI practice is to store your certificate in virtual OU unit according the openOSI naming scheme without relying on the distinguished name of the certificate. See certCheck, CAcertsRetrieve, and CRLcertsRetrieve

---

Return to top of page topSSL

Check your FQDN host name

---

Configure virtual host name if desired virtualHostname

Details about virtual hosting of web services is out of the scope of this document.

Be Careful By nature the SSL - TLS protocol doesn't support virtual hosting on the same port, unlike unencrypted http protocol. This is because the SSL connection is checked before it's virtual name processing. If you want to enable SSL virtual hosts you should choose alternate ports (one for each virtualhost), see portSSL, or alternate network interface if present.

You configure the virtual hostname in /etc/httpd/conf.d/ssl.conf within a virtual host section. Then, you configure the certificate's SSL directives inside (SSLCertificateFile, SSLCertificateKeyFile, SSLCertificateChainFile, SSLCACertificateFile, SSLCARevocationPath).

---

Return to top of page topSSL

Use openssl to generate a certificate request virtual-host.csr

The outputs will be

1. a private key, without password, with RSA coding and 1024 bit coding key named virtual-host.key
2. a PKCS10 format certificate signing request named virtual-host.csr

Option You may want to first generate the private key, then the signing request  [root@example-host conf.d]# openssl genrsa -out virtual-host.key 1024  [root@example-host conf.d]# openssl req -nodes -new -key virtual-host.key -out virtual-host.csr You may also want a shorter key length (i.e: 512 instead of 1024), if exchanged data are not sensitive, processing will be faster, unless you have SSL accelerator hardware.

To verify the content of your signing certificate request (CSR)

For more detailed information hit openssl request reference

---

Return to top of page topSSL

Filling your certificate subject

This subject is bind to the cryptographic material of your certificate. Here is the real nature of a certificate. Therefore a certificate for httpd should be bind to the virtual host running the service
see virtualHostname.

Assign your host name to common name component. ie: cn=virtual-host.example.com
The others, optional, parts of the subject are

1. Either a set of Organisation name and Country code_ ie: o=My_Organisation, c=US
2. Either a set of many Domain Components ie: "dc=example,dc=com" standing for example.com
3. Optionally you may have organisation units ie: ou=Finance or ou=hosts or ou=services
4. Optionally you may have additional cn as used by Microsoft naming scheme (cn=My_Name,cn=Users,..)

Finally you obtain your subject value called a Distinguished Name abreviated as DN

1. example 1: cn=virtual-host.example.com
2. example 2: cn=virtual-host.example.com,o=My_Organisation,c=US
3. example 3: cn=virtual-host.example.com,dc=example,dc=com
4. example 4: cn=example-host.example.com,ou=hosts,dc=example,dc=com
5. example 5: cn=virtual-host.example.com,ou=Virtualhosts,dc=example,dc=com

This is the OSI naming scheme, also used in LDAP directories (like Microsoft AD) and X400 mail systems. If your certificate is stored in an LDAP directory, it could be stored in the same DIT (Directory Information Tree) as the one of it's Distinguished name, or it could be stored under another DIT.
openOSI stores the public signed certificates this way for class 1

• DIT is "ou=VirtualHosts,dc=openosi,dc=org"
• ObjectClass=top, ObjectClass=Device, ObjectClass=StrongAuthenticationUser
• cn=virtual-host.example.com - The cn value of certificate subject
• userCertificate="Binary form of your public certificate"

That is, if requesting an openOSI signed certificate, there is no need to fill something else than the common name as your host name, because openOSI will not certify additional information for its class 1 certification. Others parts like "o=My_Organisation, c=US" will be removed from the certificate unless you require a class 2 certificate (not available for now and subject to peer agreement).

Handy Hint If you choose to generate yourself a certificate request (CSR) using openssl or any other tools including Microsoft windows based tools it could be mandatory to fill all attributes like country, organisation, organisation unit, location .... We recommend you enter as few information as possible, entering blanks where appropriate, because a certification authority is supposed to verify all the requested attributes. This is not necessary for httpd operations and is costly (however the CA could silently drop some of your unverified attributes). Many HOW TO on internet suggest you create self signed certificates which avoid this problem. We don't recommend this unless you have the ability to manage a complete secure PKI (Public Key Infrastructure) to handle secure storage, directories, renewals and revocations. openOSI offers you a free open source PKI infrastructure for class 1 / 2 certification.

Here is the openssl dialog

---

Return to top of page topSSL

Verify your certificate purpose: client/server authentication

• If you use an on line submission, choose the appropriate submission form
• If you generate your request use the appropriate template
  • If you use openssl check /etc/pki/tls/openssl.cnf for
    • nsCertType= server,client
    • keyUsage= digitalSignature,keyEncipherment
    • default is to have nothing which allows all usage for your certificate, avoid this!

Key usage should be:

• Digital signature
• Key encipherment
• Data encipherment

Extended key usage should be (see RFC 3280):

• Server auth(include OID=1.3.6.1.5.5.7.3.1)
• client auth (include OID=1.3.6.1.5.5.7.3.2)

---

Return to top of page topSSL

Retrieve your signed certificate

You can retrieve your certificate from an on line certification authority or from an LDAP directory. In the later case you could only retrieve the public key, providing the private key was generated locally.

• For an on line retrieval go the appropriate URL of the certification authority
• For an LDAP retrieval, launch an LDAP query
  • ie: for openOSI LDAP directory use the following URI
    

    ldap://directory.openosi,org/ou=VirtualHost,dc=openosi,dc=org?userCertificate?one?cn=virtual-host.example.com

---

Return to top of page topSSL

Verify your certificate purpose

You may use several tools to edit your certificate, including Windows, providing the file have an appropriate file extension corresponding to its format(.crt for DER format which is different from PEM). Conversion tools are out of the scope of this document.

When editing the certificate details under "Enhanced key usage" it should show
Server Authentication(1.3.6.1.5.5.7.3.1)
Client Authentication(1.3.6.1.5.5.7.3.2)

When editing the certificate details under "key usage" it should show
Key Encipherment, Data Encipherment(b0)

There is an openssl command to verify the purpose
In the example the certificate file name is: virtual-host.example.com.pem using PEM format

Verify certificate chain with Certification authority certificate file name: virtual-hostCA.crt
Should answer as shown

Be careful A certificate with no purpose (or Any Purpose : Yes) is a security risk. It could be misused if it is silently stolen from your host with its private key. It could allow anybody to impersonate you or any of your hosts daemons over the Internet. This risk is greater when you have not appropriate Public Key Infrastructure managing revocation lists of certificates. It's a good practice to limit the certificate to its main purpose AND to set it as critical. Be aware that silent defaults of most openssl HOW TO over Internet build any purpose certificates

---

Return to top of page topSSL

check the content of your signed certificate for a correct cn

This cn should contain the FQDN of your host see virtualHostname
The subject (DN) could be slightly different of the request because the Certification authority has removed the attributes it can't verify under its current policy (namely a level of assurance of class 1, 2 ...). This policy is indicated as a certificate practice statement or CPS

You may use several tools to edit your certificate, including Windows, providing the file have an appropriate file extension corresponding to its format(.crt for DER format which is different from PEM). Conversion tools are out of the scope of this document.

When editing the certificate details under "Subject", it should show
The order is not important
DC = com
DC = example
OU = VirtualHosts
CN = virtual-host.example.com

When editing the certificate details with openssl command line, it should show:
In the example the certificate file name is: virtual-host.example.com.pem using PEM format

Note that DC and OU components MAY be empty. CN component MUST be present and reflect your fully qualified host name (or SSL virtual host name)

---

Return to top of page topSSL

Get your associated certificate private key

Either locally or from the online enrollment

If it is from an on line certification authority, you probably retrieve a bundle of

• Your private key
• You signed certificate
• The Certification Authority certificate(s)

It comes in PKCS12 format (with .p12 extension for MS Windows)
You will have to export all the components to PEM format
Although the PKCS12 bundle is protected by a password, you should export your SSL TLS private key with no password (as for a web server).

To export the private key from a PKCS12 bundle of name virtual-host.p12

For more detailed information hit openssl pkcs12 reference

---

Return to top of page topSSL

Retrieve the Certification Authority certificate(s)

If you used the openOSI Certification authority you will get the certificates here.

• Intermediate CA certificate of class 1: openosiCA1-DC
• Root CA certificate of class 3: openosiCA3-FR

http://openosi.org/digitalkeys/ca/

You can also check our LDAP directory

If you have received a PKCS12 bundle of name virtual-host.p12

Create a hash symbolic link to the CA certificates in the same directory to speed up access.
Use the following command

---

Return to top of page topSSL

Retrieve the Certification Authority CRL (certificate revocation list)

You can also check our LDAP directory

Otherwise you should check the value of "CRL Distribution points" in your certificate details, to get the appropriate URL.

---

Return to top of page topSSL

Update certificate repository with CRLs in /etc/pki/tls/crls

You also need to create a symbolic link to the hash of your crls as with certificates. But before, you should convert the CRL files you retrieve to PEM format. CRL files are often provided in DER format to fit browsers needs.

Counvert crl from der format to pem format
This example is with openosi crl files names, replace as appropriate to feet your needs

Create the symbolic link to the hash
This example is with openosi crl files names, replace as appropriate to feet your needs

---

Return to top of page topSSL

Setup a cron job to retrieve regularly updated CRLs

Be Careful A Certificate revocation list is an important security feature. It allows checking for revoked certificates. When a certificate owner feels that a private key was compromised he revokes the certificate and get a new one.

Cron job example for openOSI
No need to update the hash (the subject name doesn't change)
replace as appropriate to feet your needs

---

Return to top of page topSSL

Decide if you want to keep default Certification authorities bundled file

Generally it is ca-bundle.crt as used in our example of ssl.conf

These external CA certificates are used for TLS authentication. From that point of view, the more you have, more likely you could authenticate a peer.

Useful Information If your certification authority certificate is not by default in that bundle of your remote clients, they will be prompted to accept your CA certificate.

If you want a small ca-bundle.crt you could copy additional CA certificates in the CA certificate path that is indicated in our example httpd configuration. You could also go this way to keep the default ca-bundle.crt file untouched and set additional accepted CA (Certification authorities).

Handy Hint Do not forget to set a hash symbolic link to the certificate. See CAcertsRetrieve

---

Return to top of page topSSL

Choose your SSL port (default: Listen 443) portSSL

As already stated the SSL / TLS protocol supports only one hostname with each couple of network interface and port. If you have several virtual host names you should attached them to different network interface or port.

It is common to use a Linux box as a reverse proxy for httpd (web firewall). That is: Internet requests are received by the remote proxy, filtered, and forwarded to one or more internal hosts (transparently for the client). In case of SSL connection, you MAY want to also encrypt exchanges between the reverse proxy and internal hosts.

1. update /etc/httpd/conf.d/ssl.conf
   • SSLProxyMachineCertificateFile /etc/pki/tls/certs/proxy-host.crt
   • SSLProxyMachineCertificatePath /etc/pki/tls/certs/proxies
   • SSLProxyCACertificateFile /etc/pki/tls/certs/cacert.pem
   • SSLProxyCACertificatePath /etc/pki/tls/certs/trust
   • SSLProxyCACertificatePath /etc/pki/tls/crls
     

In this example we used proxy-host as the name of a proxied internal host whith certificate file name of proxy-host.crt. We used "/etc/pki/tls/certs/proxies" as the example directory were certificates of several proxied internal hosts are located.

Warning SSLProxyCACertificateFile and SSLProxyCACertificatePath values set the authorization level for establishing a verified connection, providing trust CA certificates are in this example file "/etc/pki/tls/certs/cacert.pem" or this example directory "/etc/pki/tls/certs/trust"

You ask for a verified connection with the following statement in /etc/httpd/cond.d/ssl.conf

Be Careful What is verified is the acceptability of the signing CA as stated above, but NOT the name of the proxied internal host stored in the certificate subject (DN: with CN=proxy-host.example.com)

The depth is the maximum number of intermediate certificate issuers, i.e. the number of CA certificates which are max allowed to be followed while verifying the remote server certificate. A depth of 0 means that self-signed remote server certificates are accepted only, the default depth of 1 means the remote server certificate can be self-signed or has to be signed by a CA which is directly known to the server

You could use information extracted from certificates to authenticate clients, providing you trust their issuing certification authority (CA). This is a Single Sign On (SSO) solution, where no additional identification, username or passwords are required from the client. The authorization level still rely on client applications if they understand httpd authentication variables.

1. Understand related httpd environment variables variablesSSL
2. Set client certificate verification (command: SSLVerifyClient)SSLVerifyClient
3. Choose which CA you want to trust trustCA
4. Set Authentication option
   • Choose SSLUserName directive (command: SSLUserName) SSLUserName
   • Or choose SSLOption FakeBasic (command: SSLOptions) SSLOptions
5. Choose an autorization scheme authschemeSSL
   • httpd mod_auth_basic when you know all clients (command: AuthType Basic)
   • or SSLRequire for complex boolean or regex expression applied to the client certificate SSLRequire
6. Refine with OID policy definition or adoption of external ones

---

Understand related httpd environment variables

Example list
...
SSL_CLIENT_S_DN string Subject DN in client's certificate
SSL_CLIENT_S_DN_x509 string Component of client's Subject DN
SSL_CLIENT_I_DN string Issuer DN of client's certificate
SSL_CLIENT_I_DN_x509 string Component of client's Issuer DN
...

x509 specifies a component of an X.509 DN; one of C,ST,L,O,OU,CN,T,I,G,S,D,UID,Email. In Apache 2.1 and later, x509 may also include a numeric _n suffix. If the DN in question contains multiple attributes of the same name, this suffix is used as an index to select a particular attribute. For example, where the server certificate subject DN included two OU fields, SSL_SERVER_S_DN_OU_0 and SSL_SERVER_S_DN_OU_1 could be used to reference each.

Virtualy any component of the certififcate subject can be addressed (i.e: SSL_CLIENT_I_DN_Email for e-mail). There is a complete list here that could be used to define an autorization scheme, see SSLRequire

---

Return to top of page topsslAUTH

1. Set client certificate verification

Update /etc/httpd/conf.d/ssl.conf

The depth is the maximum number of intermediate certificate issuers, i.e. the number of CA certificates which are max allowed to be followed while verifying the client certificate. A depth of 0 means that self-signed client certificates are accepted only, the default depth of 1 means the client certificate can be self-signed or has to be signed by a CA which is directly known to the server.

You have more detailed information here

---

Return to top of page topsslAUTH

Choose which CA you want to trust (This is your authentication level)

You have roughly the following alternatives (you can mix)

• Trusting all default certification authorities
• Trusting a selected set of external certification authorities
• Trusting only the CA you use for your certificates
• Trusting a subset of the CAs you use for your certificates

When SSL is started, the remote client trust your CA certificate. When you want to verify the client certificate, it is verified if its signing CA certificate is present in your CA trust file or trust path. That is bundle file ca-bundle.crt- and/or _trust directory.

You get the remote CA certificate as you get your's CA certificate, or by any other trust mean. You should also similarly create a hash link where example-CAcert.crt is a certificate file.

Useful Information You may not need to retrieve the remote signing CA certificate because it is already in your trust path. That is in the following "distro" default file, which is a bundle of many certification authorities: SSLCertificateChainFile /etc/pki/tls/certs/ca-bundle.crt

Warning With the default bundled file, you accept any client having a signed certificate from these CA. Of course you can modify yourself the CA bundled file, adding or removing CA certififcates.

Best practice is:

• Use SSLCertificateChainFile to set path to a file containing the CA certificate(s) of your host. Use SSLCACertificateFile only if you also want to accept for client authentication, certificate coming from your Host CA (which is usually a bad idea, because one can impersonate whith private key of your SSL host)
• Use SSLCACertificatePath to set path to a directory containing trusted certificates of accepted CA
• If you want to trust part or all certificates from default ca-bundle.crt, split them individually and put them in your SSLCACertificatePath. Therefore you know who you trust.
  

Be Careful If you use Certification Authorities (CA) of different assurance levels, and want to authenticate users according these levels, you should set one SSL configuration with its own port for each CA level. That is you should dedicate a port for a given authentication level, relying on given settings of SSLCACertificatePath .

---

Return to top of page topsslAUTH

Choose SSLUserName directive

If you want to use the REMOTE_USER standard environment variable with certificates, assign a subject component.

Update /etc/httpd/conf.d/ssl.conf
Example: assign Subject cn (Common name) from client certificate subject DN

You can choose any of the SSL environment variables, check here variablesSL and here

Warning Up to version "httpd-2.2.2-1.2" when you use "SSLUserName" directive to set "REMOTE_USER" environment variable, you cannot map "SSL_CLIENT_S_DN_UID", because of historical reasons (in fact a bug). Therefore you cannot set SSLUserName to the certificate DN "UID value". HTTPD doesn't recognize correct UID value submitted in certificate subject DN. HTTPD recognize uniqueIdentifier X520 UID value with OID 2.5.4.45, AND depending on openssl version used for compilation, not same value is set. Certificates use commonly UserId value with OID 0.9.2342.19200300.100.1.1 for UID . Note that "X.520 UID" also named "x500UniqueIdentifier" is a bit string that NOBODY uses as UID, although it is valid to do so. If you really want to use UID from certificate, you should set its value in OID 2.5.4.45 of the subject component (not a standard feature of most CA, therefore not recommended unless you know what you are doing). Remind that most others applications will not recognize this X520 UID, and as it contains a bit string you could get unexpected results.

---

Return to top of page topsslAUTH

Set Authentication option (command: SSLOptions)

The main relevant option is FakeBasicAuth meaning: When this option is enabled, the Subject Distinguished Name (DN) of the Client X509 Certificate is translated into a HTTP Basic Authorization username. This means that the standard Apache authentication methods can be used for access control. By default, the user name is just the Subject (DN) of the Client's X509 Certificate.
Update /etc/httpd/conf.d/ssl.conf

Be Careful StrictRequire forces forbidden access when SSLRequireSSL or SSLRequire successfully decided that access should be forbidden. Usually the default is that in the case where a ``Satisfy any'' directive is used, and other access restrictions are passed, denial of access due to SSLRequireSSL or SSLRequire is overridden (because that's how the Apache Satisfy mechanism should work.) But for strict access restriction you can use SSLRequireSSL and/or SSLRequire in combination with an ``SSLOptions +StrictRequire''. Then an additional ``Satisfy Any'' has no chance once mod_ssl has decided to deny access

You have more detailed information here

---

Return to top of page topsslAUTH

Choose an autorization scheme

You may either use

• A complex boolean expression applied to the client DN (certificate subject)see SSLRequire
• A password database containing all clients with mod_auth_basic

Useful Information No password is obtained from the user. When a "httpd.passwd" file is needed, use this default password: `xxj31ZMTZzkVA', which is the DES-encrypted version of the word `password'. Those who live under MD5-based encryption (for instance under FreeBSD or BSD/OS, etc.) should use the following MD5 hash of the same word: ``$1$OXLyS...$Owx8s2/m9/gfkcRVXzgoE/''

Update /etc/httpd/conf.d/ssl.conf
Where "Example Authentication" is an arbitrary phrase

---

Return to top of page topsslAUTH

Autorization with a complex boolean expression applied to the client DN

In that scheme, it is more efficient if you have a prior knowledge of the DN (Distinguished name) structure ontained in the certificate subject. By definition, any number of expression combination can be applied as filter. We just show an example that rely on openOSI certification authority policies and DIT (Directory information tree) see also information related to your OSI name scheme:

Discussion

As already stated the subject contained in a certificate request, MAY not be fully validated by the certification authority (CA). That is: for class 1 certificates, as signed by openosiCA1-DC certification authority for people, verification is based on e-mail. Therefore a standard OU value is applied (ou=Virtualpeople) along with DC components (dc=openosi,dc=org), whereas cn=<Your_NickName>. "SubjectAltName=<Your e-mail>" is present, but outside the subject DN. If the PKCS10 certificate request (CSR) contained other OU, O .... data, they are removed because they can't be verified by this class of CA (class 1). This can be automatically checked when processing the OID number reprsenting the applied policy by the CA, see here. Other class of CA or other certification authority may have a different policy.

Useful Information When there is a SubjectAltName, that is not empty and with i.e. e-mail address, the certificate subject could be empty. Note that it is deprecated to put the e-mail address in the subject using component E, while required by some S/MIME implementations.

*Example of autorization based on filtering OU and DC components:
Where "m/?example.com/" is a regex expression.

Policy Check

In general terms you could check if an appropriate policy is embedded in the certificate through an OID, before granting access.

The OID() function expects to find zero or more instances of the given OID in the client certificate, and compares the left-hand side string against the value of matching OID attributes. Every matching OID is checked, until a match is found.

Example

You have more detailed information here

REMINDER

• Self-signed certificate usage is discouraged unless for non production environments
• Rudimentary openssl PKI usage is discouraged unless for non production environments
• Keep your certification revocation lists (CRL) up to date
• Downgrade to kerberos_V when SSL auth is unavailable, see here or here (pam with kerberos)
• LDAP directory is an identity repository, not an authentication nor an authorization service

and as usual
...

• Always check your trusted certification authorities (CA)
• Check the CA CPS (Certificate practice statement)to learn about the security policy
• Do not disable SELinux targeted
• Try to use -Multi categories security_ (MCS) to protect your files
• Use yum to update your packages
• Avoid to compile and install packages versions not supported / tested by your distro
• Have as many as possible linux box to handle separate services
• Use chrooted environments
• Keep Microsoft box out of Internet direct access
• Confine as much as possible RPC, XML-RPC and netbios
  ...