One place for hosting & domains

      Apache Configuration Error AH02572: Failed to configure at least one certificate and key



      Part of the Series:
      Common Apache Errors

      This tutorial series explains how to troubleshoot and fix some of the most common errors that you may encounter when using the Apache web server.

      Each tutorial in this series includes descriptions of common Apache configuration, network, filesystem, or permission errors. The series begins with an overview of the commands and log files that you can use to troubleshoot Apache. Subsequent tutorials examine specific errors in detail.

      Introduction

      Apache generates an AH02572: Failed to configure at least one certificate and key error message when it is configured to use the ssl module, but is missing a TLS/SSL public certificate and corresponding private key. The error will prevent Apache from starting up, and the error message itself will be found in Apache’s logs.

      In this tutorial you will learn how to troubleshoot an AH02572 error using the methods described in the How to Troubleshoot Common Apache Errors tutorial at the beginning of this series. You will also learn how to set the SSLCertificateFile and SSLCertificateKeyFile directives to resolve the message.

      If you have already determined that your Apache server is affected by an AH02572 error and you would like to skip the troubleshooting steps, the Adding an SSL Certificate to Apache section at the end of this tutorial explains how to resolve the error.

      Troubleshooting Using systemctl

      When you are troubleshooting an AH02572: Failed to configure at least one certificate and key error message, Apache will not be running. Its systemctl status will show a failed message.

      To examine Apache’s status with systemctl, run the following command on Ubuntu and Debian derived Linux distributions:

      Ubuntu and Debian Systems

      • sudo systemctl status apache2.service -l --no-pager

      On CentOS and Fedora systems, use this command to examine Apache’s status:

      CentOS and Fedora Systems

      • sudo systemctl status httpd.service -l --no-pager

      The -l flag will ensure that systemctl outputs the entire contents of a line, instead of substituting in ellipses () for long lines. The --no-pager flag will output the entire log to your screen without invoking a tool like less that only shows a screen of content at a time.

      You should receive output that is similar to the following:

      Output

      ● apache2.service - The Apache HTTP Server Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled) Drop-In: /lib/systemd/system/apache2.service.d └─apache2-systemd.conf Active: failed (Result: exit-code) since Fri 2020-07-31 16:02:41 UTC; 20s ago Process: 36 ExecStart=/usr/sbin/apachectl start (code=exited, status=1/FAILURE) Jul 31 16:02:41 7d6ef84b6907 systemd[1]: Starting The Apache HTTP Server... Jul 31 16:02:41 7d6ef84b6907 apachectl[36]: Action 'start' failed. Jul 31 16:02:41 7d6ef84b6907 apachectl[36]: The Apache error log may have more information. Jul 31 16:02:41 7d6ef84b6907 systemd[1]: apache2.service: Control process exited, code=exited status=1 Jul 31 16:02:41 7d6ef84b6907 systemd[1]: apache2.service: Failed with result 'exit-code'. Jul 31 16:02:41 7d6ef84b6907 systemd[1]: Failed to start The Apache HTTP Server.

      The important lines to note are the ones showing that Apache failed to start. However, there is nothing in the output that indicates an AH02572 error message. Examining the systemd logs for Apache using the journalctl command, or checking Apache’s configuration files with apachectl configtest will not help locate information that you can use to troubleshoot the error.

      To diagnose and resolve an AH02572 error, the next section explains how to examine Apache’s logs directly.

      Examining Apache’s Logs

      Apache logs diagnostic information about its internal operations to various locations, which differ depending on your Linux distribution. Typically, Apache is configured to log error messages to a separate log file from access requests in order to help with debugging, monitoring, and alerting.

      On Ubuntu and Debian-derived systems, Apache defaults to using /var/log/apache2/error.log for error messages.

      On CentOS, Fedora, and RedHat-derived systems, Apache defaults to logging errors to the /var/log/httpd/error_log file.

      To examine Apache’s logs for evidence of an AH02572 error message, use the grep utility to search for the error code in the appropriate log file for your distribution. While there are other tools like less that you could use to find evidence of an AH02572 error, grep will only display lines with the error code so you can be sure of whether you’re affected by the issue.

      Invoke grep like this on Ubuntu and Debian-derived systems:

      • sudo grep AH02572 /var/log/apache2/error.log

      On CentOS, Fedora, and RedHat-derived systems, use the following command:

      • sudo grep AH02572 /var/log/httpd/error_log

      If your Apache server is affected by an AH02572 error, you will have output like the following:

      Output

      [Mon Aug 03 13:21:47.677235 2020] [ssl:emerg] [pid 26:tid 140355819735360] AH02572: Failed to configure at least one certificate and key for 172.17.0.5:443

      If your server is affected by an AH02572 error, the next section of this tutorial explains how to resolve it, by either disabling the ssl module, or configuring Apache with a private key and public certificate file.

      Resolving an AH02572 Error

      There are three ways to resolve an AH02572 error. The first option to resolve the error is to configure Apache with a private key and public certificate that is signed by a recognized Certificate Authority (CA). Let’s Encrypt is a free CA and you can use it to issue a valid certificate. This approach will ensure that traffic to and from your server is encrypted properly, and that web browsers and other HTTP clients trust your Apache server.

      Another approach is to create a self-signed certificate for your Apache server. This approach is useful for development and testing environments, or in cases where your server is not directly connected to the Internet and you can establish trust between systems manually.

      The last approach to resolving an AH02572 error is to turn off Apache’s ssl module entirely. This option is the least preferred since traffic to and from your server will not be encrypted. However, if you are only using your Apache server for local development or in a trusted environment, this approach can be valid.

      The following sections explain how to resolve an AH02572 error using each of the three options.

      Resolving an AH02572 Error with a Let’s Encrypt TLS Certificate

      To encrypt traffic to your Apache server using a free Let’s Encrypt TLS Certificate, use one of the guides that is specific to your Linux distribution from this tutorial series: How To Secure Apache with Let’s Encrypt.

      The Let’s Encrypt process is mostly automated, and the scripts will configure Apache for you. Moreover, the issued certificate will also be renewed automatically so you do not have to worry about it expiring in the future.

      If you are using a Linux distribution that is not included in the How To Secure Apache with Let’s Encrypt series, the Let’s Encrypt documentation includes links to interactive Certbot instructions that can help you configure your Apache server with a valid TLS certificate.

      Resolving an AH02572 Error with a Self-Signed Certificate

      To encrypt traffic to your Apache server using a self-signed certificate, use one of the tutorials from this series that explains how to create Self-signed SSL Certificates with Apache.

      These tutorials demonstrate how to generate a private key and public certificate for your Apache server. They also demonstrate how to use the SSLCertificateFile and SSLCertificateKeyFile Apache directives to configure your server with the certificate that you generate.

      If you are not using a distribution that is listed in the Self-signed SSL Certificates with Apache set of tutorials, this OpenSSL Essentials: Working with SSL Certificates, Private Keys and CSRs guide can help you create a private key and self-signed public certificate that you can use with Apache.

      Note: Where possible, it is best to use a free Let’s Encrypt certificate, or other commercially issued TLS certificate. Self-signed TLS certificates are not trusted by default by browsers and other HTTP clients. As a result, your users will see a security error when visiting your site. However, if you are doing local development, or your use case does not require a valid TLS certificate you can opt for the self-signed approach.

      Disabling the ssl Module

      The last approach to resolving an AH02572 error is to turn off Apache’s TLS/SSL support by disabling the ssl module. This approach is less desirable than encrypting traffic to your server with a TLS certificate, so be certain that you do not need TLS support before disabling the module.

      To disable Apache’s ssl module on Ubuntu and Debian-derived systems, run the following command:

      On CentOS, Fedora, and RedHat-derived systems, disable the module with the following command:

      • sudo rm /etc/httpd/conf.modules.d/00-ssl.conf

      Once you have disabled the ssl module, run apachectl to test that the configuration is valid.

      • sudo apachectl configtest

      A successful apachectl configtest invocation should result in output like this:

      Output

      Syntax OK

      You can now restart Apache using the appropriate systemctl restart command for your Linux distribution.

      On Ubuntu and Debian-derived systems, run the following:

      • sudo systemctl restart apache2.service

      On CentOS, Fedora, and RedHat-derived systems use this command to restart Apache:

      • sudo systemctl restart httpd.service

      If there are no errors from the systemctl command then you have disabled the ssl module successfully.

      Conclusion

      AH02572: Failed to configure at least one certificate and key errors are challenging to detect and troubleshoot. They cannot be diagnosed with the usual systemctl, journalctl, and apachectl commands. In this tutorial you learned how to use the grep utility to examine Apache’s logs directly for evidence of an AH02572 error.

      Next you learned how to use Let’s Encrypt to configure Apache with a TLS certificate to secure your traffic and resolve the AH02572 error. You also learned about using self-signed TLS certificates for development and isolated environments. Finally you learned how to turn off the ssl module for those situations where it is not needed.



      Source link

      Cloud Security Tips for Financial Services: 5 Key Takeaways from an Industry Expert


      Today we are pleased to welcome guest blogger Tony Bradley, Senior Manager of Content Marketing for Alert Logic, INAP’s trusted managed security partner and expert in cloud security for financial services customers.
      – Wendy Williams, Product Manager, INAP

      Show me the money, and I’ll show you a cybercriminal ready to attack.

      The sophistication of digital financial services and mobile banking have greatly expanded the attack surface criminals can exploit. While technology has given us the luxuries of quickly depositing a check via our mobile device or shopping online, it has also created ever evolving security challenges.

      Planning your cloud security strategy? Below are five key takeaways for IT infrastructure pros in the financial services space:

      1. Moving to the cloud changes the entire approach to security. A comprehensive view of your environment is critical, so choose a partner who can provide security monitoring of the environment, as well as network intrusion detection, vulnerability management and log management.

      2. The level of expertise and the amount of people needed to maintain compliance using exclusively in-house services is cost prohibitive for all but the rarest of enterprises. The best options are to evaluate a trusted managed services partner or adopt technology that integrates services as part of the solution.

      3. eCommerce has paved the way to unprecedented growth and revenue but opens doors to exponential compliance and threat risks. Using public cloud providers calls for 24/7 platform security. It is important to understand who has what security responsibility when utilizing cloud platforms and service providers. Furthermore, it pays to spend time evaluating whether or not your solution provider and partner have a deep understanding of your preferred platform. If they don’t, look elsewhere. This approach will ensure hard-to-detect web attacks such as SQL injection, path traversal and cross-site scripting risks are mitigated.

      4. A solution may complement in-house capabilities, however, sometimes getting the right resources becomes a balancing act. As the hottest market today, security experts are scarce. In fact, according to (ISC)2, a non-profit IT security organization, there are an estimated 2.93 million cybersecurity positions open and unfilled around the world. The best advice is to develop a relationship with a service provider and a partner who can truly be an extension of your internal team and who has both the technology and resources to ensure constant surveillance, as well as the ability to stand up to any rigorous compliance audit.

      5. We’ve only just witnessed the beginning of technologies touting AI capabilities. If you’re ready to adopt an AI-based solution for cybersecurity, ensure that it can draw on data sets of wildly different types, allowing the “bigger picture” to become clear from not only static configuration data and historic local logs but global threat landscapes and concurrent event streams, as well.

      It’s more important than ever for businesses in the financial services industry to have the right tools and partners in place. Remember: Any solution you choose should be more than widgets and a slick UI. Too much is on the line. The road to holistic cloud security begins with proper implementation and infrastructure design, detailed, best practice configuration, and a plan for continuous monitoring and threat response. Chat with our partners at INAP today to get started.

       

      About the Author

      Tony Bradley is Senior Manager of Content Marketing for Alert Logic. Tony worked in the trenches as a network administrator and security consultant before shifting to the marketing and writing side of things. He is an 11-time Microsoft MVP in security and cloud and has been a CISSP-ISSAP since 2002. Tony has authored or co-authored a dozen books on IT and IT security topics, and is a prolific contributor to online media sites such as Forbes and DevOps.com.

      Wendy Williams
      • Product Manager, Private Cloud and Security Services


      READ MORE



      Source link

      Colocation Pricing Guide: Power, Space and Key Questions to Ask Your Provider


      Migration of infrastructure to colocation facilities will continue full force for the next few years, according to a survey put out to 500 IT professionals. Why? Because most on-prem data centers can’t compare to Tier 3-design facilities. The best colocation data centers offer high uptime, power efficiency and redundancy, as well as improve the physical security of infrastructure. With an enterprise colocation solution, companies also have access to greater networking capabilities and public cloud and/or other multi-platform solutions. This flexibility future-proofs your infrastructure for whatever needs may arise over time.

      Considering colocation as part of your infrastructure mix? Here’s our colo pricing guide to help you understand power, space and the key questions to ask your provider to decide the best fit for your company.

      What You Need to Know About Colocation Pricing

      Below, you’ll find the common types of billing for power, the spacing options you can choose from and two examples of how power and space are billed together.

      Start with Your Power Needs

      There are four standard ways to bill for power. When you’re working with your colocation provider, ensure they’re gathering your current and future power needs to appropriately size the power circuits. With that information in hand, they should work to offer you the best deal and least costly solution.

      There are four billing types for power:

      1. Per Circuit (Flat Rate) Power Billing

      The bill is a flat monthly fee per circuit provisioned for your solution and is the most common colo pricing structure. With this model, you have price predictability. You’ll pay the same amount whether you use five percent or 80 percent of your capacity. But be warned, there is no ability to burst above 80% of the delivered power without adding additional circuits.

      2. Power Capacity kW (Allocated kW) Billing

      In this model, you make a commitment to use a fixed amount of power (i.e.: 100kW), regardless of the electrical capacity of the circuits installed. Typically, you’ll see savings over flat rate model; however, the penalties for bursting above your committed rate can be quite steep.

      3. Metered Power (Usage Based) Billing

      Your bill will vary in this model. The monthly fee is based on actual usage and is determined on the present rate per kilowatt hour. Colocation providers typically only offer this pricing model on very large deployments and customers will still have to pay for space.

      4. All In Space & Power

      This is a simple calculation of the amount of space and power presented in a per kW number. It’s a very easy way for customers to compare pricing (assuming space and power delivered is equal). A con to this solution is that both the space and power are tied to a single rate per kW so there is a loss of flexibility.  If you ever need to upgrade just the power, you’ll end up paying more for the same amount of space.

      Explore Colocation Space Options

      Colo space is typically sold by:

      Cabinet: A single lockable cabinet on the data center floor. You can purchase contiguous cabinets if they are available in your chosen data center.

      Cage or Private Suite: An enclosed, lockable, segmented cage on the data center floor that provides superior flexibility and control without the capital investments that come with building and maintaining an enterprise-grade facility. A minimum of 5 racks/cabs is standard for cage deployments, assigned at 24 square feet per rack. Private data center suites, on the hand, are built to suit (complete with separate security access points) and are used typically for larger, wholesale colo deployments.

      Remember though, for some colocation pricing models, your bill may not have anything to do with square footage or rack usage. While cabinets or square feet are still required in order to allocate an area within the data center, the price is attached to the power that is being allocated for your use.

      Common Types of Colo Pricing Solutions

      Now that we understand the options for space and power billing, let’s explore how both aspects come together with two examples of popular billing models, relative to the deployment size. Work with your colocation provider to determine your best-fit solution.

      Cabinets with flat rate circuits

      For smaller deployments, typically one to four cabinets, colocation providers will deliver lockable cabinets, each with primary and redundant (optional) power feeds. A single power feed can deliver anywhere from 2kw – 17kw depending on the colocation provider’s power capacity and cooling capabilities. Your bill would consist of line items for the cabinet(s) and circuits delivered.

      Space/kw with Usage-based Power Pricing

      This solution is for larger deployments (100kw+), as providers will typically have minimums for this solution. You’ll be billed based on the number of square feet and a variable monthly fee based on actual power usage. This monthly fee is based on a preset dollar rate per kilowatt hour. Regardless of term, installs should be charged in this model.

      Typically, there is not much of a margin built into usage-based power. You should also expect install fees when adding more circuits.

      Beyond the Price Tag: What Can the Colocation Data Center You Choose Do for You?

      When you decide to move your infrastructure off-prem, there are many other economic and performance-based factors beyond the list price for space and power; however, they are just as important to consider and can even make or break your infrastructure strategy.

      Consider the following questions:

      1. Does the colo facility have Tier 3-attributes?

      To be a Tier 3-attribute data center, the facility must maintain N+1 fault tolerance, 72-hour protection from power outages and 99.982 percent uptime. Concurrent maintainability also ensures that a single critical component failure—electrical, cooling, power, etc.— will not disrupt service because of the redundant systems in place. How does the data center you are considering stack up?

      2. Does the colo provider offer multi-platform contract flexibility?

      Infrastructure needs can change fast. Make sure your provider gives you flexibility through implementation of different platforms (cloud, bare metal, etc.), as well as spend portability after you deploy so that you can switch up your infrastructure solutions to stay agile and keep pace with you company’s goals and workloads.

      3. Does the colo provider support High Power Density environments?

      With a high-power density configuration, you can fit more gear into a smaller space and reduce your overall footprint. This becomes especially important if you’re looking to deploy any type of hyper-converged solution.

      4. Can I get high-performance, low-latency bandwidth?

      Bandwidth is an essential cost that you cannot overlook when sourcing any data center or cloud solution. If you’re powering any mission-critical applications with your colocation deployment, look for a colocation data center that has quality blend of ISPs and inquire about latency averages.

      5. Does the colo provider offer interconnectivity solutions?

      Ideally, you’ll want a provider who offers a high-capacity private network that allows you to connect across various data centers throughout the country or around the globe. If your colo provider lacks interconnectivity solutions, you’ll need to partner with other vendors for interconnectivity options, which can be a future pain point.

      6. Does your provider offer geographically dispersed data centers for disaster recovery?

      Ultimately, you may require some sort of secondary site for any disaster recovery solution as part of your overall business continuity plan. Look for a provider that either has multiple sites across the a geographically dispersed area or some sort of off-site DRaaS product that works for your company.

      7. What about onsite support?

      Onsite expert support technicians can keep your infrastructure online, secure and always operating at peak efficiency when your own IT staff is unable to. Make sure your colo provider offers remote hands support and don’t leave it out of your colo budgetary considerations. You’ll also want to ensure that your data is protected by 24/7/365 onsite security/personnel.

      For more information on colocation pricing, or to find the best solution for you, chat now.

      Explore INAP Colocation.

      LEARN MORE

      Jeff Bettencourt
      • Director, Solution Engineering


      READ MORE



      Source link