Bug 55942 - 400 - Bad Request on POST (Windows Server 2012 Hyper-V with SSL)
Summary: 400 - Bad Request on POST (Windows Server 2012 Hyper-V with SSL)
Status: NEW
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ssl (show other bugs)
Version: 2.4.4
Hardware: PC All
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-01 04:58 UTC by ev5unleash
Modified: 2019-06-19 07:14 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ev5unleash 2014-01-01 04:58:26 UTC
Hello all,

This is my first ever bug report with you guys so bare with me. To give you a bit of a background, I am currently hosting an application on a WAMP stack. For redundancy and portability I chose to move the application onto a Hyper-V Virtual Machine. I went about my business and installed the WAMP stack and made my configurations. I was careful to keep every configuration precise so I didn't cause any anomalies. 

Upon finalizing the move onto the new VM, I decided to try it. The operation of the Application seemed fine on both the un-secure and secure (SSL) vitrualhost. The problem however is the Apache webserver responding to SSL POST requests. The server either responds with 400 - BAD REQUEST or with nothing at all. 

My first steps were to verify my configs. In the end, comparing the configurations from my old server to this new VM and literally copying the installation over to the VM yield no improvements. So my next step was to look through the logs. I threw the server into debug mode and observed the logs. Something I came across was this weird corruption with the POST request. Almost 90% of all POST requests had this corruption which I'll leave an example of below:

XXX.XXX.XXX.XXX - - [28/Dec/2013:12:00:58 -0500] "3\xebPOST /client/v1/ HTTP/1.1" 200 12
XXX.XXX.XXX.XXX - - [28/Dec/2013:12:00:58 -0500] "EFPOST /client/v1/ HTTP/1.1" 200 12
XXX.XXX.XXX.XXX - - [28/Dec/2013:12:00:57 -0500] "1\x18POST /client/v1/ HTTP/1.1" 200 12
XXX.XXX.XXX.XXX - - [28/Dec/2013:12:00:53 -0500] "E=POST /client/v1/ HTTP/1.1" 200 12
XXX.XXX.XXX.XXX - - [28/Dec/2013:12:00:52 -0500] "C\x85POST /client/v1/ HTTP/1.1" 200 12

Along with these errors core would push an error like the one below:

[Fri Dec 27 22:18:47.803022 2013] [core:error] [pid 1680:tid 4516] [client XXX.XXX.XXX.XXX:49948] AH00126: Invalid URI in request t\x0cPOST /client/v1/ HTTP/1.1


Now this only seems to be an issue with POSTs over the SSL-connection. The POSTs over unsecure connections seems fine however. 

In the end, I've pretty much isolated every variable I could think of. The only thing I see changing is the difference of running the WAMP stack on a physical machine as opposed to a Hyper-V Virtual Machine. So after a week of digging around the interwebs, consulting my more tech-literate friends, and spending hours troubleshooting, I am at a loss. 

Any help would be much appreciated!





My configurations are below:

Physical Box (that works perfectly)

Intel Core i3-3217U
2x4GB of RAM (8 total)
120GB Muschkin SSD 
Intel Gigabit NIC
Windows 7

Virtualization Machine
Intel Core i5-4430
2x4GB of RAM (8 total)
128 SSD
Inttel Gigabit NIC
Windows Server 2012

Virtualization Box
4 GB RAM
80 GB Disk Space
Microsoft Virtual Switch NIC
Windows 7

[I have tried countless operating systems and other Virtualization boxes. All which have had the consistent issue]
[Other OSes I have tried for the Virtual Machine]
[Windows 7]
[Windows 8]
[Windows 8.1]
[Windows Server 2008 R2]
[Windows Server 2012]
[Windows Server 2012 R2]

[Other OSes I have tried with HyperV host]
[Windows Server 2012]
[Windows Server 2012 R2]

[Again I have tried a totally different box for hosting these VMs as well]
Comment 1 Ethan Roy 2019-06-19 07:14:23 UTC
The simplest way to configure Hyper-V Replica (HVR) authentication and transport is to use HTTP. HTTP uses Active Directory Kerberos authentication and replication over TCP port 80. However, this is only useful in a demo or between trusted domains on a secure network. What if you want to replicate between untrusted forests (customer-to-service provider) or over an untrusted network? You’ll need to venture into the murky world of x.509 certificates and configure Hyper-V Replica to authenticate using SSL and replicate over HTTPS. Today I’ll walk you through the Hyper-V Replica certificate requirements, how to choose a certificate, and how to enable per-VM replication.

Hyper-V Replica Certificate Requirements

If you want to use HTTPS authentication and replication, then you will need to create certificates for the hosts/clusters in both the primary and secondary sites.  The certificate must be configured for server authentication and client authentication. The certificate must also be issued to the FQDN of the host or HVR Broker, and it must include the exportable private keys for traffic decryption.

Note that the computer template included in Active Directory Certificate Services can be copied and used for this purpose. You will need to configure the template to grant administrators rights to enroll the certificate type and to permit the encryption keys to be exported (a requirement of the HVR certificate).

If you are creating a certificate for a non-clustered host, then make sure the certificate is created for the fully qualified domain name (FQDN) of the host in question (for example, demo-host1.demo.internal). This certificate will be installed just on this host.

In the case of a Hyper-V cluster, each clustered host will have two certificates for HVR:

1- Its own certificate: Issued and installed as if this host was not clustered (for example, demo-host3.demo.internal).

2- A certificate for the HVR Broker: This certificate is created for the cluster’s HVR Broker and installed on each node in the cluster (for example, demo-HVC1-brkr.demo.internal).

https://oneworldrental.ca/