What is Internet Information Services (IIS)?

Internet Information Services (IIS) is a versatile, extensible, and secure web server software developed by Microsoft. It serves as the foundation for hosting websites, web applications, web services, and FTP sites on Windows Server and client operating systems. IIS supports protocols such as HTTP, HTTPS, FTP, FTPS, SMTP, and NNTP, making it a multi-protocol server platform.

Introduced in the mid-1990s and continuously enhanced since, IIS has evolved into a critical component of the Windows Server ecosystem. It provides deep integration with Windows features like Active Directory, security subsystems, and management tools. IIS empowers developers to deploy applications built with technologies including ASP.NET, PHP, and classic ASP, while supporting extensibility through modules and handlers.

IIS is widely adopted in enterprise environments due to its reliability, scalability, security features, and rich management capabilities.

Major Use Cases of Internet Information Services (IIS)

IIS is employed across various business and technology domains. Key use cases include:

1. Hosting Enterprise Websites

IIS hosts corporate websites, portals, and public-facing web applications that require robust security, high availability, and easy management.

2. ASP.NET and .NET Web Applications

IIS is the de facto hosting environment for ASP.NET applications, offering seamless integration with the .NET framework and runtime.

3. Web Services and APIs

Companies deploy SOAP and RESTful web services on IIS to expose application functionality for integration with other systems, mobile apps, or partners.

4. FTP Services

IIS provides FTP/FTPS services to facilitate secure file transfer and management for internal and external users.

5. Intranet and Collaboration Portals

Many organizations use IIS to host intranet sites and collaboration tools like SharePoint.

6. Secure SSL/TLS Hosting

IIS manages SSL/TLS certificates to provide secure HTTPS connections, essential for ecommerce, banking, and sensitive data applications.

7. Load Balancing and Web Farms

IIS supports load balancing across multiple servers, enabling horizontal scaling and fault tolerance for large-scale deployments.

8. Content Caching and Compression

To improve performance and reduce bandwidth, IIS offers static and dynamic content caching and compression features.

9. Application Pool Isolation

IIS isolates web applications into separate application pools to prevent one application failure from impacting others, enhancing stability and security.

How Internet Information Services (IIS) Works Along with Architecture

Understanding IIS requires exploring its multi-layered, modular architecture that manages request processing, security, and application hosting.

1. HTTP.SYS Kernel Mode Driver

At the lowest level, IIS uses the Windows kernel-mode HTTP driver called HTTP.SYS. It listens on HTTP/HTTPS ports, receives incoming HTTP requests, queues them, and routes them to appropriate worker processes. HTTP.SYS provides high-performance HTTP processing, caching, logging, and security filtering.

2. World Wide Web Publishing Service (W3SVC)

This service manages website configurations, processes incoming requests from HTTP.SYS, and distributes them to worker processes in application pools.

3. Application Pools

An application pool is a container for one or more worker processes (w3wp.exe) that host one or more web applications. Pools isolate applications for better reliability, security, and resource management. Each pool can have its own identity, runtime version, and recycling settings.

4. Worker Processes

Worker processes execute the code for web applications. They process HTTP requests, invoke modules and handlers, and generate responses. Worker processes load ISAPI extensions or .NET CLR hosting depending on application types.

5. Request Processing Pipeline

IIS request handling is modular:

• Modules: Process requests in a pipeline manner. Modules handle authentication, authorization, caching, compression, URL rewriting, logging, and more. Some modules run in kernel mode, others in user mode.
• Handlers: Responsible for processing specific types of requests or file extensions (e.g., static files, ASP.NET pages, PHP scripts).

Developers and administrators can add or remove modules and handlers to customize the pipeline.

6. Configuration System

IIS uses a hierarchical configuration system:

• applicationHost.config: Global server configuration.
• web.config: Per-application or folder configuration.

Configurations define sites, application pools, bindings, authentication, security rules, and more. Settings cascade and can be overridden at various levels.

7. Management Tools

• IIS Manager: Graphical interface for site, application pool, and server configuration.
• AppCmd.exe: Command-line utility for automation.
• PowerShell Cmdlets: Rich scripting and automation.
• Windows Management Instrumentation (WMI): Programmatic access for management.

Basic Workflow of Internet Information Services (IIS)

1. Client Request Arrival An HTTP/HTTPS request arrives at the server’s IP and port.
2. HTTP.SYS Handling HTTP.SYS intercepts the request, performs preliminary filtering, and queues it.
3. Site and Application Pool Routing IIS routes the request to the corresponding site and its associated application pool.
4. Worker Process Processing The worker process receives the request and initiates the request pipeline.
5. Module Execution Modules sequentially process the request through authentication, authorization, URL rewriting, caching, and more.
6. Handler Invocation The handler processes the request (e.g., serving static content, executing ASP.NET code).
7. Response Generation The worker process generates the HTTP response based on the handler’s output.
8. Response Sent to Client The response is sent back via HTTP.SYS and over the network to the client.
9. Logging and Diagnostics IIS logs the request, response, and any errors for monitoring and troubleshooting.

Step-by-Step Getting Started Guide for Internet Information Services (IIS)

Step 1: Install IIS

• On Windows Server:
  • Open Server Manager.
  • Select Add Roles and Features.
  • Choose Web Server (IIS) and required features.
• On Windows 10/11:
  • Open Control Panel > Programs > Turn Windows features on or off.
  • Enable Internet Information Services.

Alternatively, use PowerShell:

Install-WindowsFeature -Name Web-Server -IncludeManagementTools

Step 2: Launch IIS Manager

• Press Win + R, type inetmgr, press Enter.
• Explore the GUI for managing sites, application pools, and server settings.

Step 3: Add and Configure a Website

• Right-click Sites > Add Website.
• Specify:
  • Site name.
  • Physical path (directory with your website files).
  • Binding information (IP, port, hostname).
• Click OK.

Step 4: Deploy Web Content

• Place HTML, ASP.NET, or other content into the site’s physical directory.

Step 5: Manage Application Pools

• Select the application pool assigned to your site.
• Configure settings such as .NET CLR version, pipeline mode (Integrated or Classic), recycling intervals, and identities.

Step 6: Test Your Website

• Open a browser and navigate to your site URL (e.g., http://localhost).
• Verify it loads properly.

Step 7: Secure Your Website

• Obtain and install SSL certificates.
• Bind HTTPS with the SSL certificate via IIS Manager.

Step 8: Enable Logging and Diagnostics

• In IIS Manager, enable logging under the Logging feature.
• Configure log file locations and formats.
• Use Failed Request Tracing for advanced diagnostics.

Step 9: Automate Management (Optional)

• Use AppCmd.exe for scriptable management.
• Use PowerShell IIS modules for advanced automation.

The post Mastering Internet Information Services (IIS): Architecture, Use Cases, and Setup Guide appeared first on scmGalaxy.

What is NGINX Proxy?

NGINX Proxy is a highly efficient reverse proxy and load balancer server used to manage web traffic and distribute it across multiple backend servers. NGINX (pronounced “Engine-X”) is well-known for its high performance, scalability, and reliability. It is often used in production environments to serve static files, handle dynamic requests, and proxy HTTP/HTTPS traffic to backend services like web servers, application servers, or even microservices.

In the context of a reverse proxy, NGINX Proxy acts as an intermediary between clients (users’ browsers or APIs) and one or more backend servers. It receives requests from clients and forwards them to the appropriate backend server, ensuring that the traffic is efficiently routed.

Major Use Cases of NGINX Proxy

NGINX Proxy is highly versatile, serving a wide array of use cases:

1. Load Balancing

• Distribute Requests Across Servers: NGINX Proxy can evenly distribute incoming requests across multiple servers, preventing any one server from becoming overloaded.
• Enhance Availability: By balancing traffic between multiple instances, NGINX ensures high availability and improved fault tolerance.

2. Reverse Proxy for Web Servers

• Forward Requests to Backend Servers: NGINX acts as a reverse proxy by forwarding client requests to backend web servers (like Apache or application servers), ensuring that only one point of contact is exposed to the client.
• TLS Termination: It handles TLS/SSL encryption for HTTPS traffic, offloading the work from backend servers and improving performance.

3. Caching

• Improved Performance: NGINX Proxy can cache content (static files, API responses, etc.) at the edge, reducing the load on backend servers and improving the response time.
• Cache Control: You can control how long certain content stays in the cache, enabling more efficient use of resources.

4. Security & Access Control

• Hide Backend Servers: By acting as a reverse proxy, NGINX Proxy hides the details of backend infrastructure from the outside world, adding a layer of security.
• Access Restriction: NGINX Proxy can restrict access to certain backend resources based on IP, URL, or other parameters.

5. API Gateway for Microservices

• Manage Microservices Traffic: In microservices architectures, NGINX Proxy can serve as an API Gateway, managing requests and routing them to appropriate microservices.
• Centralized Authentication and Logging: It handles authentication (like OAuth2 or JWT), request logging, and rate limiting across microservices.

How NGINX Proxy Works (Architecture Overview)

The architecture of NGINX Proxy revolves around request handling, traffic distribution, and security management. Here’s a breakdown of its components and workflow:

Key Components of NGINX Proxy:

1. NGINX Server:
   • The NGINX Proxy server receives all incoming HTTP/S traffic and directs it based on configuration to one or more backend servers.
   • NGINX can serve static files (like images, HTML, CSS, etc.) and pass dynamic content requests to backend servers like PHP, Python, or Node.js.
2. Backend Servers:
   • These are the servers where your web applications or APIs are hosted. NGINX Proxy routes requests to these servers, which process the requests and return the response to NGINX.
3. Load Balancing Mechanism:
   • NGINX supports multiple load balancing algorithms, including round-robin, least connections, and IP-hash. These algorithms determine how incoming requests are distributed across multiple backend servers.
4. TLS Termination:
   • NGINX Proxy handles SSL/TLS encryption and decryption for secure HTTPS traffic, offloading this computationally expensive task from the backend servers.
5. Caching Layer:
   • NGINX Proxy can cache responses from backend servers, reducing the number of requests that need to be processed and improving response times for frequently requested resources.
6. Access Control & Security:
   • NGINX Proxy provides robust features for managing access, including restricting traffic from certain IP addresses, applying rate limits, and blocking malicious traffic.

NGINX Proxy Flow:

1. Request Reception: The client makes an HTTP request (e.g., for a webpage or API).
2. DNS Resolution: The domain name is resolved to the IP of the NGINX Proxy server.
3. Routing & Load Balancing: NGINX Proxy evaluates the request, possibly using load balancing algorithms to route it to one of several backend servers.
4. SSL/TLS Termination: If the request is HTTPS, NGINX Proxy terminates the SSL/TLS handshake and decrypts the data.
5. Request Forwarding: NGINX forwards the request to the appropriate backend server.
6. Response: The backend server processes the request and returns a response to NGINX.
7. Caching (Optional): NGINX Proxy may cache the response and send it back to the client, reducing future load on the backend.
8. Client Response: NGINX sends the response back to the client.

Basic Workflow of NGINX Proxy

The basic workflow of NGINX Proxy involves:

1. Configuration Setup:
   • Define upstream servers (backend servers) and proxy rules.
   • Configure load balancing, SSL termination, and caching.
2. Traffic Reception:
   • NGINX Proxy receives incoming client requests on specified ports (usually HTTP 80 and HTTPS 443).
3. Request Routing:
   • NGINX Proxy checks the request headers, including the host and path, to determine which backend server should handle the request.
4. Handling Response:
   • After receiving the response from the backend server, NGINX Proxy may perform additional actions like caching, compression, or content rewriting.
5. Response Delivery:
   • The response is delivered back to the client, potentially utilizing caching to speed up future requests.

Step-by-Step Getting Started Guide for NGINX Proxy

Prerequisites:

• Basic understanding of Docker and NGINX.
• Docker and Docker Compose installed.

Step 1: Set Up Docker Environment

1. Install Docker and Docker Compose on your system if not already installed.
2. Create a docker-compose.yml file for the NGINX Proxy container and your backend services:

version: '3'
services:
  nginx-proxy:
    image: jwilder/nginx-proxy
    container_name: nginx-proxy
    environment:
      - DEFAULT_HOST=default.local
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock:ro

  webapp:
    image: your-web-app-image
    environment:
      - VIRTUAL_HOST=webapp.example.com
      - VIRTUAL_PORT=80
    expose:
      - "80"

Step 2: Launch NGINX Proxy

Start the services using Docker Compose:

docker-compose up -d

This will start NGINX Proxy and your backend web application container.

Step 3: Test the Reverse Proxy

Once the containers are running, navigate to http://webapp.example.com in your browser. NGINX Proxy should route the request to the webapp container, and the application should respond.

Step 4: Set Up SSL (Optional)

To enable SSL using Let’s Encrypt, you can add environment variables for SSL certificate management:

  nginx-proxy:
    image: jwilder/nginx-proxy
    container_name: nginx-proxy
    environment:
      - VIRTUAL_HOST=webapp.example.com
      - LETSENCRYPT_HOST=webapp.example.com
      - LETSENCRYPT_EMAIL=your-email@example.com
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock:ro

The post NGINX Proxy: Optimizing Web Traffic and Enhancing Performance appeared first on scmGalaxy.

Go to App\config\mail.php

lets open mail.php file and paste below code.

‘stream’ => [
‘ssl’ => [
‘allow_self_signed’ => true,
‘verify_peer’ => false,
‘verify_peer_name’ => false,
],
],

And now Got your activation mail successfully.

The post stream_socket_enable_crypto(): SSL operation failed with code 1. OpenSSL Error messages: appeared first on scmGalaxy.

My Application(.ear) is running in Jboss with any issues on 7001 port. There are following requirement as such with me.

Task 1. Integrate Jboss with Apache2 so all the request should be coming from Apache Instead of jboss

Task 2. Implement SSLwith apache2 so it should open with https instead of http.

For task 1, I have followed carefully community.jboss.org/wiki/UsingModjk12WithJBoss with some issues. 1. Application is getting up and running without any issues but logout has some issues. 2. I want to stop JBOSS access point but not getting any clue

For task 2 Once this is up and running, i will have to implement SSL with Apache so it should only get open with HTTPS instead of http. any help on this front as well..any links or Reference.

To follow this issues properly, you can find my work update on this link..I will keep posted the issues…

The post Integration of Jboss and Apache2 and SSL appeared first on scmGalaxy.

Guide to Understading SSL Certificates

The post A Guide to Understanding SSL Certificates appeared first on scmGalaxy.

HTTPS

Hypertext Transfer Protocol Secure (HTTPS) is a combination of the Hypertext Transfer Protocol with the SSL/TLS protocol to provide encrypted communication and secure identification of a network web server. HTTPS connections are often used for payment transactions on the World Wide Web and for sensitive transactions in corporate information systems.

Secure socket layer (SSL): how it works

1.   An SSL certificate enables encryption of sensitive information during online transactions.

2.   Each SSL certificate is a unique credential identifying the certificate owner.

3.   A certificate Authority authenticates the identity of a certificate owner before it is issued.
What is SSL and Certificate

The Secure Socket Layer protocol was created by Netscape to ensure secure transactions between web servers and browsers. The protocol uses a third party, a Certificate Authority (CA), to identify one end or both end of the transactions. This is in short how it works.

• A browser requests a secure page (usually https://).
• The web server sends its public key with its certificate.
• The browser checks that the certificate was issued by a trusted party (usually a trusted root CA), that the certificate is still valid and that the certificate is related to the site contacted.
• The browser then uses the public key, to encrypt a random symmetric encryption key and sends it to the server with the encrypted URL required as well as other encrypted http data.
• The web server decrypts the symmetric encryption key using its private key and uses the symmetric key to decrypt the URL and http data.
• The web server sends back the requested html document and http data encrypted with the symmetric key.
• The browser decrypts the http data and html document using the symmetric key and displays the information.

• A browser attempts to connect to a Web site secured with SSL.

keytool -genkey -alias bf-sandbox -keyalg RSA -keystore buildForgeKeyStore.p12 -keysize 2048

[root@ tmp]# keytool -genkey -alias bf-sandbox -keyalg RSA -keystore buildForgeKeyStore.p12 -keysize 2048
Enter key store password: XXXX
Enter key password for : XXX

You are about to enter information that will be incorporated into
your certificate request.  This information is what is called a
Distinguished Name or DN.  There are quite a few fields but you
can use supplied default values, displayed between brackets, by just
hitting , or blank the field by entering the character
before hitting .

keytool -certreq -sigalg RSA -alias bf-sandbox -file bf-sandbox.csr -keystore buildForgeKeyStore.p1Insallation Certificates in BuildForge

Point 1: You would need to update the bfclient.conf to make Build Forge aware of the certifications. As long as the certificates are in the correct it will work with Build Forge.

Point 2: The easiest way to update the cert would be change the new cert name to the name of the previous cerr. Then update the passwords.

Point 3:
Please use the following command to validate the keystore:

keytool -list -storetype pkcs12 -keystore fullyQualifiedNameOfFile.p12 -v

The Symmetric key

Well, Private Key/Public Key encryption algorithms are great, but they are not usually practical. It is asymmetric because you need the other key pair to decrypt. You can’t use the same key to encrypt and decrypt. An algorithm using the same key to decrypt and encrypt is deemed to have a symmetric key. A symmetric algorithm is much faster in doing its job than an asymmetric algorithm. But a symmetric key is potentially highly insecure. If the enemy gets hold of the key then you have no more secret information. You must therefore transmit the key to the other party without the enemy getting its hands on it. As you know, nothing is secure on the Internet. The solution is to encapsulate the symmetric key inside a message encrypted with an asymmetric algorithm. You have never transmitted your private key to anybody, then the message encrypted with the public key is secure (relatively secure, nothing is certain except death and taxes). The symmetric key is also chosen randomly, so that if the symmetric secret key is discovered then the next transaction will be totally different.

Encryption algorithm:

There are several encryption algorithms available, using symmetric or asymmetric methods, with keys of various lengths. Usually, algorithms cannot be patented, if Henri Poincare had patented his algorithms, then he would have been able to sue Albert Einstein… So algorithms cannot be patented except mainly in USA. OpenSSL is developed in a country where algorithms cannot be patented and where encryption technology is not reserved to state agencies like military and secret services. During the negotiation between browser and web server, the applications will indicate to each other a list of algorithms that can be understood ranked by order of preference. The common preferred algorithm is then chosen. OpenSSL can be compiled with or without certain algorithms, so that it can be used in many countries where restrictions apply.

The Hash:

A hash is a number given by a hash function from a message. This is a one way function, it means that it is impossible to get the original message knowing the hash. However the hash will drastically change even for the slightest modification in the message. It is therefore extremely difficult to modify a message while keeping its original hash. It is also called a message digest. Hash functions are used in password mechanisms, in certifying that applications are original (MD5 sum), and in general in ensuring that any message has not been tampered with. It seems that the Internet Enginering Task Force (IETF) prefers SHA1 over MD5 for a number of technical reasons (Cf RFC2459 7.1.2 and 7.1.3).

Signing:

Signing a message, means authentifying that you have yourself assured the authenticity of the message (most of the time it means you are the author, but not neccesarily). The message can be a text message, or someone else’s certificate. To sign a message, you create its hash, and then encrypt the hash with your private key, you then add the encrypted hash and your signed certificate with the message. The recipient will recreate the message hash, decrypts the encrypted hash using your well known public key stored in your signed certificate, check that both hash are equals and finally check the certificate.
The other advantage of signing your messages is that you transmit your public key and certificate automatically to all your recipients.
There are usually 2 ways to sign, encapsulating the text message inside the signature (with delimiters), or encoding the message altogether with the signature. This later form is a very simple encryption form as any software can decrypt it if it can read the embedded public key. The advantage of the first form is that the message is human readable allowing any non complaint client to pass the message as is for the user to read, while the second form does not even allow to read part of the message if it has been tampered with.

PassPhrase:

“A passprase is like a password except it is longer”. In the early days passwords on Unix system were limited to 8 characters, so the term passphrase for longer passwords. Longer is the password harder it is to guess. Nowadays Unix systems use MD5 hashes which have no limitation in length of the password.

Public Key Infrastructure

The Public Key Infrastructure (PKI) is the software management system and database system that allows to sign certifcate, keep a list of revoked certificates, distribute public key,… You can usually access it via a website and/or ldap server. There will be also some people checking that you are who you are… For securing individual applications, you can use any well known commercial PKI as their root CA certificate is most likely to be inside your browser/application. The problem is for securing e-mail, either you get a generic type certificate for your e-mail or you must pay about USD100 a year per certificate/e-mail address. There is also no way to find someone’s public key if you have never received a prior e-mail with his certificate (including his public key).

The post Know about Certificates and SSLs appeared first on scmGalaxy.

Problem

[root@sv-chef-server mychefrepo]# sudo knife node list
ERROR: SSL Validation failure connecting to host: 10.0.0.134 - SSL_connect returned=1 errno=0 state=error: certificate verify failed
ERROR: Could not establish a secure connection to the server.
Use `knife ssl check` to troubleshoot your SSL configuration.
If your Chef Server uses a self-signed certificate, you can use
`knife ssl fetch` to make knife trust the server's certificates.

Original Exception: OpenSSL::SSL::SSLError: SSL Error connecting to https://10.0.0.134/organizations/mysvhcl/nodes - SSL_connect returned=1 errno=0 state=error: certificate verify failed

Solution

Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

The post Error: SSL Validation failure connecting to host appeared first on scmGalaxy.