Red Hat SummitEste conteúdo não está disponível no idioma selecionado.
Chapter 11. Configuring certificate profiles
As part of the installation process of a CA, the certificate enrollment profiles can be modified directly on the file system by modifying the profiles' configuration files. Default files exist for the default profiles at installation; when new profiles are needed, new profile configuration files are to be created. The configuration files are stored in the CA profile directory, instance_directory/ca/profiles/ca/, such as /var/lib/pki/pki-ca/ca/profiles/ca/. The file is named profile_name.cfg. All of the parameters for profile rules can be set or modified in those profile configuration files. Profile rules can be inputs, outputs, authentication, authorization, defaults, and constraints.
The enrollment profiles for the CA certificates are located in the /var/lib/pki/instance_name/ca/conf directory with the name *.profile.
For audit reasons, use this method only during the CA installation prior to deployment.
Restart the server after editing the profile configuration file for the changes to take effect.
11.1. Configuring non-CA system certificate profiles
11.1.1. Profile configuration parameters
All of the parameters for a profile rule - defaults, inputs, outputs, and constraints - are configured within a single policy set. A policy set for a profile has the name policyset.policyName.policyNumber. For example:
policyset.cmcUserCertSet.6.constraint.class_id=noConstraintImpl policyset.cmcUserCertSet.6.constraint.name=No Constraint policyset.cmcUserCertSet.6.default.class_id=userExtensionDefaultImpl policyset.cmcUserCertSet.6.default.name=User Supplied Key Default policyset.cmcUserCertSet.6.default.params.userExtOID=2.5.29.15
policyset.cmcUserCertSet.6.constraint.class_id=noConstraintImpl
policyset.cmcUserCertSet.6.constraint.name=No Constraint
policyset.cmcUserCertSet.6.default.class_id=userExtensionDefaultImpl
policyset.cmcUserCertSet.6.default.name=User Supplied Key Default
policyset.cmcUserCertSet.6.default.params.userExtOID=2.5.29.15The common profile configuration parameters are described in Table 11.1, “Profile configuration file parameters”.
| Parameter | Description |
|---|---|
| desc | Gives a free text description of the certificate profile, which is shown on the end-entities page. For example, desc=This certificate profile is for enrolling server certificates with agent authentication. |
| enable | Sets whether the profile is enabled, and therefore accessible through the end-entities page. For example, enable=true. |
| auth.instance_id |
Sets which authentication manager plugin to use to authenticate the certificate request submitted through the profile. For automatic enrollment, the CA issues a certificate immediately if the authentication is successful. If authentication fails or there is no authentication plugin specified, the request is queued to be manually approved by an agent. For example, auth.instance_id=CMCAuth. The authentication method must be one of the registered authentication instances from |
| authz.acl | Specifies the authorization constraint. Most commonly, this us used to set the group evaluation ACL. For example, this caCMCUserCert parameter requires that the signer of the CMC request belong to the Certificate Manager Agents group: authz.acl=group="Certificate Manager Agents" In directory-based user certificate renewal, this option is used to ensure that the original requester and the currently-authenticated user are the same.
An entity must authenticate (bind or, essentially, log into the system) before authorization can be evaluated. The authorization method specified must be one of the registered authorization instances from |
| name | Gives the name of the profile. For example, name=Agent-Authenticated Server Certificate Enrollment. This name is displayed in the end users enrollment or renewal page. |
| input.list | Lists the allowed inputs for the profile by name. For example, input.list=i1,i2. |
| input.input_id.class_id | Gives the java class name for the input by input ID (the name of the input listed in input.list). For example, input.i1.class_id=cmcCertReqInputImpl. |
| output.list | Lists the possible output formats for the profile by name. For example, output.list=o1. |
| output.output_id.class_id | Gives the java class name for the output format named in output.list. For example, output.o1.class_id=certOutputImpl. |
| policyset.list | Lists the configured profile rules. For dual certificates, one set of rules applies to the signing key and the other to the encryption key. Single certificates use only one set of profile rules. For example, policyset.list=serverCertSet. |
| policyset.policyset_id.list | Lists the policies within the policy set configured for the profile by policy ID number in the order in which they should be evaluated. For example, policyset.serverCertSet.list=1,2,3,4,5,6,7,8. |
| policyset._policyset_id.policy_number._constraint.class_id | Gives the java class name of the constraint plugin set for the default configured in the profile rule. For example, policyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl. |
| policyset._policyset_id.policy_number._constraint.name | Gives the user-defined name of the constraint. For example, policyset.serverCertSet.1.constraint.name=Subject Name Constraint. |
| policyset.policyset_id.policy_number._constraint.params._attribute | Specifies a value for an allowed attribute for the constraint. The possible attributes vary depending on the type of constraint. For example, policyset.serverCertSet.1.constraint.params.pattern=CN=.*. |
| policyset._policyset_id.policy_number._default.class_id | Gives the java class name for the default set in the profile rule. For example, policyset.serverCertSet.1.default.class_id=userSubjectNameDefaultImpl |
| policyset._policyset_id.policy_number._default.name | Gives the user-defined name of the default. For example, policyset.serverCertSet.1.default.name=Subject Name Default |
| policyset.policyset_id.policy_number._default.params._attribute | Specifies a value for an allowed attribute for the default. The possible attributes vary depending on the type of default. For example, policyset.serverCertSet.1.default.params.name=CN=(Name)$request.requestor_name$. |
11.1.2. Modifying certificate extensions directly on the file system
Changing constraints changes the restrictions on the type of information which can be supplied. Changing the defaults and constraints can also add, delete, or modify the extensions which are accepted or required from a certificate request.
For example, the default caFullCMCUserCert profile is set to create a Key Usage extension from information in the request.
The default is updated to allow user-supplied key extensions:
policyset.cmcUserCertSet.6.default.class_id=userExtensionDefaultImpl policyset.cmcUserCertSet.6.default.name=User Supplied Key Default policyset.cmcUserCertSet.6.default.params.userExtOID=2.5.29.15
policyset.cmcUserCertSet.6.default.class_id=userExtensionDefaultImpl
policyset.cmcUserCertSet.6.default.name=User Supplied Key Default
policyset.cmcUserCertSet.6.default.params.userExtOID=2.5.29.15
This sets the server to accept the extension OID 2.5.29.15 in the certificate request.
Other constraints and defaults can be changed similarly. Make sure that any required constraints are included with appropriate defaults, that defaults are changed when a different constraint is required, and that only allowed constraints are used with the default. For more information, see the B.1 Defaults Reference and B.2 Constraints Reference reference sections in the Administration Guide (Common Criteria Edition).
11.1.2.1. key usage and extended key usage consistency
Red Hat Certificate System provides a flexible infrastructure for administrators to create customized enrollment profiles to meet the requirements of their environment. However, it is important that profiles do not allow issuing certificates that violate the requirements defined in RFC 5280. When creating an enrollment profile where both Key Usage (KU) and Extended Key Usage (EKU) extensions are present, it is important to make sure that the consistency between the two extensions is maintained as per section 4.2.1.12. Extended Key Usage of RFC 5280.
For details about the KU extension, see:
The following table provides the guidelines that maps consistent Key Usage bits to the Extended Key Usage Extension for each purpose:
| Purpose / Extended Key Usages | Key Usages |
|---|---|
| TLS Server Authentication command id-kp-serverAuth | digitalSignature, keyEncipherment, or KeyAgreement |
| TLS Client (Mutual) Authentication id-kp-clientAuth | digitalSignature, keyEncipherment, and/or KeyAgreement |
| Code Signing id-kp-codeSigning | digitalSignature |
| Email Protection id-kp-emailProtection | digitalSignature, nonRepudiation, and/or (keyEncipherment or keyAgreement) |
| OCSP Response Signing id-kp-OCSPSigning | KeyAgreement and/or nonRepudiation |
The following shows two examples of inconsistent EKU/KU:
An enrollment profile that is intended for purpose of OCSP response signing contains Extended key usage
id-kp-OCSPSigningbut withkeyEnciphermentkey usage bit:Copy to Clipboard Copied! Toggle word wrap Toggle overflow An enrollment profile that is intended for the purpose of TLS server authentication contains Extended key
usage id-kp-serverAuthbut with CRL signing key usage bit:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
For details about the KU extension, see:
- B.2.3 Key Usage Extension Constraint in the Administration Guide (Common Criteria Edition).
- B.3.8 keyUsage in the Administration Guide (Common Criteria Edition).
For details about the EKU extension, see:
- B.2.3 Extended Key Usage Extension Constraint in the Administration Guide (Common Criteria Edition).
- B.3.6 extKeyUsage in the Administration Guide (Common Criteria Edition).
11.1.2.2. Configuring cross-pair profiles
Cross-pair certificates are distinct CA signing certificates that establish a trust partner relationship whereby entities from these two distinct PKIs will trust each other. Both partner CAs store the other CA signing certificate in its database, so all of the certificates issued within the other PKI are trusted and recognized.
Two extensions supported by the Certificate System can be used to establish such a trust partner relationship (cross-certification):
-
The Certificate Policies Extension (
CertificatePoliciesExtension) specifies the terms that the certificate fall under, which is often unique for each PKI. -
The Policy Mapping Extension (
PolicyMappingExtension) seals the trust between two PKI’s by mapping the certificate profiles of the two environments.
Issuing cross-pair certificates requires the Certificate Policies Extension, explained in the B.3.4 certificatePoliciesExt annex in the Administration Guide (Common Criteria Edition).
To ensure that the issued certificate contains the CertificatePoliciesExtension, the enrollment profile needs to include an appropriate policy rule, for example:
Certificates issued with the enrollment profile in this example would contain the following information:
Identifier: Certificate Policies: - 2.5.29.32 Critical: no Certificate Policies: Policy Identifier: 1.1.1.1
Identifier: Certificate Policies: - 2.5.29.32
Critical: no
Certificate Policies:
Policy Identifier: 1.1.1.1For more information on using cross-pair certificates, see 13.4 Using Cross-Pair Certificates in the Administration Guide (Common Criteria Edition).
For more information on publishing cross-pair certificates, see 7.8 Publishing Cross-Pair Certificates in the Administration Guide (Common Criteria Edition).
11.1.3. Adding profile inputs directly on the file system
The certificate profile configuration file in the CA’s profiles/ca directory contains the input information for that particular certificate profile form. Inputs are the fields in the end-entities page enrollment forms. There is a parameter, input.list, which lists the inputs included in that profile. Other parameters define the inputs; these are identified by the format input.ID. For example, this adds a generic input to a profile:
For more information on what inputs, or form fields, are available, see the A.1 Input Reference annex in the Administration Guide (Common Criteria Edition).
11.2. Changing the default validity time of certificates
In each profile on a Certificate Authority (CA), you can set how long certificates issued using a profile are valid. You can change this value for security reasons.
For example, to set the validity of the generated Certificate Authority (CA) signing certificate to 825 days (approximately 27 months), open the /var/lib/pki/instance_name/ca/profiles/ca/caCACert.cfg file in an editor and set:
policyset.caCertSet.2.default.params.range=825
policyset.caCertSet.2.default.params.range=82511.3. Setting the signing algorithm default in a profile
Each profile has a Signing Algorithm Default extension defined. The default has two settings: a default algorithm and a list of allowed algorithms, if the certificate request specifies a different algorithm. If no signing algorithms are specified, then the profile uses whatever is set as the default for the CA.
In the profile’s .cfg file, the algorithm is set with two parameters:
The - value for the policyset.cmcUserCertSet.8.default.params.signingAlg parameter means that the default signing algorithm will be used.
11.4. Configuring CA system certificate profiles
Unlike the non-CA subsystems, the enrollment profiles for CA’s own system certificates are kept in the /var/lib/pki/[instance name]/ca/conf file. Those profiles are:
-
caAuditSigningCert.profile -
eccAdminCert.profile -
rsaAdminCert.profile -
caCert.profile -
eccServerCert.profile -
saServerCert.profile -
caOCSPCert.profile -
eccSubsystemCert.profile -
rsaSubsystemCert.profile
11.4.1. Changing the default values of certificate profiles
If you wish to change the default values in the profiles above, make changes to the profiles before you perform the second step of a two-step installation (as described in Between step customization). The following is an example that demonstrates:
- How to change validity to CA signing certificate.
How to add extensions (e.g. Certificate policies extension).
Back up the original CA certificate profile used by
pkispawn.cp -p /usr/share/pki/ca/conf/caCert.profile /usr/share/pki/ca/conf/caCert.profile.orig
# cp -p /usr/share/pki/ca/conf/caCert.profile /usr/share/pki/ca/conf/caCert.profile.origCopy to Clipboard Copied! Toggle word wrap Toggle overflow Open the CA certificate profile used by the configuration wizard.
vim /usr/share/pki/ca/conf/caCert.profile
# vim /usr/share/pki/ca/conf/caCert.profileCopy to Clipboard Copied! Toggle word wrap Toggle overflow Reset the validity period in the
Validity Defaultto your desired value. For example, to change the period to two years:2.default.class=com.netscape.cms.profile.def.ValidityDefault 2.default.name=Validity Default 2.default.params.range=720
2.default.class=com.netscape.cms.profile.def.ValidityDefault 2.default.name=Validity Default 2.default.params.range=720Copy to Clipboard Copied! Toggle word wrap Toggle overflow Add any extensions by creating a new default entry in the profile and adding it to the list. For example, to add the
Certificate Policies Extension, add the default (which, in this example, is default #9):Copy to Clipboard Copied! Toggle word wrap Toggle overflow Then, add the default number to the list of defaults to use the new default:
list=2,4,5,6,7,8,9
list=2,4,5,6,7,8,9Copy to Clipboard Copied! Toggle word wrap Toggle overflow
11.4.2. Allowing a CA certificate to be renewed past the validity period
Normally, a certificate cannot be issued with a validity period that ends after the issuing CA certificate’s expiration date. If a CA certificate has an expiration date of December 31, 2023, then all of the certificates it issues must expire by or before December 31, 2023.
This rule applies to other CA signing certificates issued by a CA - and this makes renewing a root CA certificate almost impossible. Renewing a CA signing certificate means it would necessarily have to have a validity period past its own expiration date.
This behavior can be altered using the CA Validity Default. This default allows a setting (bypassCAnotafter) which allows a CA certificate to be issued with a validity period that extends past the issuing CA’s expiration (notAfter) date.
Figure 11.1. CA validity default configuration
In real deployments, what this means is that a CA certificate for a root CA can be renewed, when it might otherwise be prevented.
To enable CA certificate renewals past the original CA’s validity date:
Stop the CA:
systemctl stop pki-tomcatd@instance_name.service
# systemctl stop pki-tomcatd@instance_name.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow OR if using the Nuxwdog watchdog:
systemctl stop pki-tomcatd-nuxwdog@instance_name.service
# systemctl stop pki-tomcatd-nuxwdog@instance_name.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow Open the
caCACert.cfgfile.var/lib/pki/instance_name/ca/profiles/ca/caCACert.cfg
# var/lib/pki/instance_name/ca/profiles/ca/caCACert.cfgCopy to Clipboard Copied! Toggle word wrap Toggle overflow The CA Validity Default should be present by default. Set the value to
trueto allow a CA certificate to be renewed past the issuing CA’s validity period.policyset.caCertSet.2.default.name=CA Certificate Validity Default policyset.caCertSet.2.default.params.range=2922 policyset.caCertSet.2.default.params.startTime=0 policyset.caCertSet.2.default.params.bypassCAnotafter=true
policyset.caCertSet.2.default.name=CA Certificate Validity Default policyset.caCertSet.2.default.params.range=2922 policyset.caCertSet.2.default.params.startTime=0 policyset.caCertSet.2.default.params.bypassCAnotafter=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow Start the CA to apply the changes.
systemctl start pki-tomcatd@instance_name.service
# systemctl start pki-tomcatd@instance_name.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow OR if using the Nuxwdog watchdog:
systemctl start pki-tomcatd-nuxwdog@instance_name.service
# systemctl start pki-tomcatd-nuxwdog@instance_name.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow
When an agent reviews a renewal request, there is an option in the Extensions/Fields area that allows the agent to choose to bypass the normal validity period constraint. If the agent selects false, the constraint is enforced, even if bypassCAnotafter=true is set in the profile. If the agent selects true when the bypassCAnotafter value is not enabled, then the renewal request is rejected by the CA.
Figure 11.2. Bypass CA constraints option in the agent services page
The CA Validity Default only applies to CA signing certificate renewals. Other certificates must still be issued and renewed within the CA’s validity period.
A separate configuration setting for the CA, ca.enablePastCATime, can be used to allow certificates to be renewed past the CA’s validity period. However, this applies to every certificate issued by that CA. Because of the potential security issues, this setting is not recommended for production environments.
11.5. Managing smart card CA profiles
Features in this section on TMS are not tested in the evaluation. This section is for reference only.
The TPS does not generate or approve certificate requests; it sends any requests approved through the Enterprise Security Client to the configured CA to issue the certificate. This means that the CA actually contains the profiles to use for tokens and smart cards. The profiles to use can be automatically assigned, based on the card type.
The profile configuration files are in the /var/lib/instance_name/ca/profiles/ca/ directory with the other CA profiles. The default profiles are listed in Table 11.2, “Default token certificate profiles”.
| Profile Name | Configuration File | Description |
|---|---|---|
| Regular Enrollment Profiles | ||
| Token Device Key Enrollment | caTokenDeviceKeyEnrollment.cfg | For enrolling tokens used for devices or servers. |
| Token User Encryption Certificate Enrollment | caTokenUserEncryptionKeyEnrollment.cfg | For enrolling encryption certificates on the token for a user. |
| Token User Signing Certificate Enrollment | caTokenUserSigningKeyEnrollment.cfg | For enrolling signing certificates on the token for a user. |
| Token User MS Login Certificate Enrollment | caTokenMSLoginEnrollment.cfg | For enrolling user certificates to use for single sign-on to a Windows domain or PC. |
| Temporary Token Profiles | ||
| Temporary Device Certificate Enrollment | caTempTokenDeviceKeyEnrollment.cfg | For enrolling certificates for a device on a temporary token. |
| Temporary Token User Encryption Certificate Enrollment | caTempTokenUserEncryptionKeyEnrollment.cfg | For enrolling an encryption certificate on a temporary token for a user. |
| Temporary Token User Signing Certificate Enrollment | caTempTokenUserSigningKeyEnrollment.cfg | For enrolling a signing certificates on a temporary token for a user. |
| Renewal Profiles | ||
| Token User Encryption Certificate Enrollment (Renewal) | caTokenUserEncryptionKeyRenewal.cfg | For renewing encryption certificates on the token for a user, if renewal is allowed. |
| Token User Signing Certificate Enrollment (Renewal) | caTokenUserSigningKeyRenewal.cfg | For renewing signing certificates on the token for a user, if renewal is allowed. |
Renewal profiles can only be used in conjunction with the profile that issued the original certificate. There are two settings that are beneficial:
- It is important the original enrollment profile name does not change.
- The Renew Grace Period Constraint should be set in the original enrollment profile. This defines the amount of time before and after the certificate’s expiration date when the user is allowed to renew the certificate. There are only a few examples of these in the default profiles, and they are mostly not enabled by default.
11.5.1. Editing enrollment profiles for the tps
Administrators have the ability to customize the default smart card enrollment profiles, used with the TPS. For instance, a profile could be edited to include the user’s email address in the Subject Alternative Name extension. The email address for the user is retrieved from the authentication directory. To configure the CA for LDAP access, change the following parameters in the profile files, with the appropriate directory information:
These CA profiles come with LDAP lookup disabled by default. The ldapStringAttributes parameter tells the CA which LDAP attributes to retrieve from the company directory. For example, if the directory contains uid as an LDAP attribute name, and this will be used in the subject name of the certificate, then uid must be listed in the ldapStringAttributes parameter, and request.uid listed as one of the components in the dnpattern.
Editing certificate profiles is covered in 3.2 Setting up Certificate Profiles in the Administration Guide (Common Criteria Edition).
The format for the dnpattern parameter is covered in the B.2.11 Subject Name Constraint annex and B.1.27 Subject Name Default references in the Administration Guide (Common Criteria Edition).
11.5.2. Creating custom TPS profiles
Certificate profiles are created as normal in the CA, but they also have to be configured in the TPS for it to be available for token enrollments.
New profiles are added with new releases of Red Hat Certificate System. If you migrate an instance to Red Hat Certificate System 10, then you need to add the new profiles to the migrated instance as if they are custom profiles.
- Create a new token profile for the issuing CA. Setting up profiles is covered in 3.2 Setting up Certificate Profiles in the Administration Guide (Common Criteria Edition).
-
Copy the profile into the CA’s profiles directory,
/var/lib/instance_name/ca/profiles/ca/. Edit the CA’s
CS.cfgfile, and add the new profile references and the profile name to the CA’s list of profiles. For example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Edit the TPS
CS.cfgfile, and add a line to point to the new CA enrollment profile. For example:vim /etc/pki/instance_name/tps/CS.cfg
# vim /etc/pki/instance_name/tps/CS.cfg op.enroll.userKey.keyGen.signing.ca.profileId=tpsExampleEnrollProfileCopy to Clipboard Copied! Toggle word wrap Toggle overflow Restart the instance after editing the smart card profiles:
systemctl restart pki-tomcatd-nuxwdog@instance_name.service
# systemctl restart pki-tomcatd-nuxwdog@instance_name.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow If the CA and TPS are in separate instances, restart both instances.
Enrollment profiles for the External Registration (externalReg) setting are configured in the user LDAP entry.
11.5.3. Using the Windows smart card logon profile
The TPS uses a profile to generate certificates to use for single sign-on to a Windows domain or PC; this is the Token User MS Login Certificate Enrollment profile (caTokenMSLoginEnrollment.cfg).
However, there are some special considerations that administrators must account for when configuring Windows smart card login.
- Issue a certificate to the domain controller, if it is not already configured for TLS.
- Configure the smart card login per user, rather than as a global policy, to prevent locking out the domain administrator.
- Enable CRL publishing to the Active Directory server because the domain controller checks the CRL at every login.
11.6. Disabling certificate enrollment profiles
This section provides instructions on how to disable selected profiles.
To disable a certificate profile, edit the corresponding *.cfg file in the /var/lib/pki/instance_name/ca/profiles/ca/ directory and set the visible and enable parameters to false.
For example, to disable all non-CMC profiles:
List all non-CMC profiles:
ls -l /var/lib/pki/instance_name/ca/profiles/ca/ | grep -v "CMC"
# ls -l /var/lib/pki/instance_name/ca/profiles/ca/ | grep -v "CMC"Copy to Clipboard Copied! Toggle word wrap Toggle overflow In each of the displayed files, set the following parameters to
false:visible=false enable=false
visible=false enable=falseCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Additionally, set visible=false in all CMC profiles to make them invisible on the end entity page:
List all CMC profiles:
ls -l /var/lib/pki/instance_name/ca/profiles/ca/*CMC*
# ls -l /var/lib/pki/instance_name/ca/profiles/ca/*CMC*Copy to Clipboard Copied! Toggle word wrap Toggle overflow In each of the displayed files, set:
visible=false
visible=falseCopy to Clipboard Copied! Toggle word wrap Toggle overflow
For an alternative way to disable non-CMC profiles, also see Section 7.6.5, “Disable non-CMC and non-installation profiles”.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}