Configure Apache and F5 loadbalancer.
From Apache layer we generate CSR and get the trusted cer as:
1) .cer
2) .p7b
Then I convert the .cer and .p7b file to .crt file and configure in our apache as keyfile, certificate and chain.
We are facing some issue while configuring the SSL between F5 and Apache. Our flow is:
Client(SSL) -> F5 (SSL drops ) -> (recreate ssl to apache layer) -> Apache webserver.
1) create CSR from apache web layer, get sign as trusted from the company (not external)
2) configure in ssl.conf and ciphersuite
Now initiate a request using openssl it is throwing:
depth = 1
DC = net
DC = racb
CN = XXXXXX
CA 1 verify error:num=20:unable to get local issuer certificate read from 0x1b9c8d0 [0x1ca04f3] (5 bytes => 5 (0x5))
In order to verify it I modified the /etc/hosts entry as xxx.xxx.xxx.net as 127.0.0.1 and move the chain certificate to /etc/pki/ca-trust/source/anchor and update-ca-trust extract and run the openssl which is return with error code=0 and waiting in SSL session.
What mistake we are doing in F5 no idea.
Can someone throw the lights?
If you're setting up a bridging config, you need both an SSL Client Profile (typically you take your Apache key/cert/chain) and an SSL Server Profile, and both are chosen on the Virtual Server configuration.
For the Client Profile you first need to import the private key, the certificate(s) and of course you have to see on the Certificates screen that the private key matches the certificate.
Usually for the Server Profile, if we know that we can trust the backend server, instead of setting up something with certificates of your own, we just choose the unsecure-compatible profile and it will work in almost all cases.
If there is no need to setup SNI, it's enough to make it work.
Related
Problem Background:
As part of the Computer Networking course assignment, I have been given task of implementing a Proxy Server ( using python socket and ssl module ) that handles https communications between the browser and the origin server (The real server that my browser wants to talk to).
What I have done so far:
I have implemented the above requirement using ssl sockets and also generated self-signed 'cert.pem' 'key.pem' files.
What I need to do:
Now I just need to tell my browser (chrome 89 on kubuntu 20.04) to accept this self-signed certificate and then test the working of my proxy server.
Reading from this stackoverflow question, I can see that I have to:
(1) become my own CA (2) then sign my SSL certificate as a CA. (3) Then import the CA certificate (not the SSL certificate, which goes onto my server) into Chrome.
My confusion/question:
So if I do this, when eventually I am done with this assignment, how do I reverse all these steps to get my browser in the previous state before I had made all these changes. Also, how to reverse the "become your own CA" and also delete the SSL certificates signed by my CA.
Basically, I want my system to return to the previous state it was before I would have made all these changes.
UPDATE:
I have done the previously outlined steps but now I get an error.
Here is a snippet of my code:
serv_socket = socket(AF_INET, SOCK_STREAM)
serv_socket.bind(('', serv_port))
serv_socket.setsockopt(SOL_SOCKET, SO_REUSEADDR, 1)
context = ssl.create_default_context(ssl.Purpose.CLIENT_AUTH)
context = context.load_cert_chain('cert.pem', 'key.pem')
context.set_ciphers('EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH')
serv_socket.listen(10)
socket_to_browser, addr = serv_socket.accept()
conn_socket_to_browser = context.wrap_socket(socket_to_browser, server_side=True)
At the last line conn_socket_to_browser = context.wrap_socket(socket_to_browser, server_side=True) an exception is thrown: [SSL: HTTPS_PROXY_REQUEST] https proxy request (_ssl.c:1123)
What am I doing wrong ?
As glamorous as "becoming your own CA" sounds, with openssl it basically comes down to creating a self-signed certificate, and then creating a directory where some CA-specific configuration will be stored (I don't fully remember the specifics, but I think it was just some files related to CNs and serial numbers) so basically reversing the "become your own CA" step is something as mundane as deleting this directory along with the private key and self-signed certificate you were using for the CA. That's it, the CA is no more.
And for chrome returning to the previous state, you would just go the the CA list where you added the CA certificate, select it and delete it. Chrome will stop accepting certificates signed by your CA.
Regarding your new problem... In my opinion, you have developed some kind of reverse proxy (meaning that you expect normal HTTPS requests that you then redirect to the real server) but you have configured Chrome to use it as a forward proxy. In this case, Chrome does not send it a normal HTTPS request, it sends a special non-encrypted CONNECT command and only after receiving the non-encrypted response, it negotiates the TLS connection. That's why openssl says "https proxy request" because it has detected a "https proxy request" (a CONNECT command) instead of the normal TLS negotiation.
You can take a look at How can a Python proxy server (using SSL socket) pretend to be an HTTPS server and specify my own keys to get decrypted data?
It's python, but I think that you'll get the idea
I have a simple node-opcua client and it wants to connect to a server via Basic128Rsa15 policy.
I have created a self-signed certificate and the server does receive this cert and I can move it on the server to the trusted pki directory.
At my client - the node-opcua - I also see a new directory "pki/rejected" with the cert from the server.
My question is now: What do I have to do now so that the client will trust this self-signed cert from the server?
I have already tried to create a "trusted" directory and move it to there, but this does not help, I also have tried to add an option (which I have found via google): serverCertificate=crypto_utils.readCertificate("pki/trusted/04c9f401be19e5a2349460306579c692e777cea5.pem"); But that also didn't help. When I start the client it creates again the cert in the "rejected" folder.
My node-opcua options for the connection:
options:
securityMode: 3 # None = 1, Sign = 2, SignAndEncrypt = 3
securityPolicy: "http://opcfoundation.org/UA/SecurityPolicy#Basic128Rsa15"
certificateFile: certificates/cert.pem
privateKeyFile: certificates/key.pem
[EDITED]
version 2.30 onward: node-opcua clients now perform full certificate validation coming from servers:
if a server certificate has been generated by a CA, the CA certificate must appear in the PKI of the client ( in the issuer folder) along side with the corresponding CRL.
by default the client certificate manager accepts valid unknown server certificate for backward compatibility with previous version. This can be reverted by setting the automaticallyAcceptUnknownCertificates to false.
other checks are performed to verify that the certificate of the server strictly complies to the requirements of OPCUA, such as subjectAltName.uniqueResourceIdentify must match server's applicationUri, keyUsage, key length etc ...
if server certificate is known and in rejected folder, client will reject connection with server.
version 2.28 and below: node-opcua clients did not perform server certificate trust/reject checks yet, nor full certificate validation, just basic validate (date, signature ...)
I am trying to create an HTTPS-tunnel on my machine. My intention is having all requests to https://localhost:8888/<something> (the port where Fiddler is listening to) be directed to https://myserver.net/<something>. I am using the following script as per Fiddler doc:
static function OnBeforeRequest(oSession: Session) {
// <Fiddler 2 preexisting code>
// HTTPS redirect -----------------------
if (oSession.HTTPMethodIs("CONNECT") &&
(oSession.PathAndQuery == "localhost:8888"))
{
oSession.PathAndQuery = "myserver.net:443";
}
if (oSession.HostnameIs("localhost"))
oSession.hostname = "myserver.net";
// --------------------------------------
// <Fiddler 2 preexisting code>
}
Also in Fiddler settings I checked the decryption check and installed certificates as you can see in the image below:
I restart Fiddler, it prompts me to install its fake certificates, I agree. I can see the certificate in my Windows Certificate System Repository when using certmgr. It is a self-signed certificate.
So What I do is opening a browser and type: https://localhost:8888/mypage.html, and what I get is an error. Internet Explorer reports this:
Error: Mismatched Address. The security certificate presented by this
website was issued for a different website's address. This problem
might indicate an attempt to fool you or intercept any data...
When I get certificate info (basically the certificate presented by the contacted host is being rejected, the same certificate can be displayed), I can see that the rejected certificate was issued by Fiddler and the subject is myserver.net.
So the certificate is ok because it is certifying myserver.net, I see that the problem is that probably my browser was expecting a certificate whose subject is localhost. Is it true?
How to handle this situation?
Assumption
I can understand that the problem is a certificate being issued for a website which I did not ask for. So the solution would be using a certificate certifying localhost:8888?
A certificate is valid if it is directly or indirectly (via intermediate certificates) signed by a trusted CA and if the hostname matches the certificate. If the last condition would not be enforced anybody with a valid certificate from a trusted CA could incorporate any other site.
To make use of fiddler and not run into this problem you should configure your browser to use fiddler as a web proxy and then use the real URL inside the browser instead of ip:port of fiddler.
I am using the EC2 Load Balancer to handle HTTPS requests. For Chrome & Safari, having the Load Balancer Protocol set HTTPs at Port 443 with the the SSL cert handles most traffic correctly. HTTPS requests from Safari & Chrome are fine. However in Firefox, I get the connection is insecure "(Error code: sec_error_unknown_issuer)." In checking with a cert checker, I get
The certificate is not signed by a trusted authority (checking against
Mozilla's root store). If you bought the certificate from a trusted
authority, you probably just need to install one or more Intermediate
certificates.
In talking with my cert provider, the information I got was :
As we can see certificate has been installed improperly at the server.
There is no CA bundle at the server that is why browsers may show
warning messages.
How do you install a CA Bundle using the Load Balancer?
The solution is to add the ca_bundle to your load_balancer under "Certificate Chain"
That depends on how you are creating the ELB (Elastic Load Balancer).
If you are creating it from the AWS Console, then, when you create the ELB you can create a new SSL sercificate and, when promted, and as #Emile said, you have to specify the contents of the provided "CA Bundle" under the "Certificate Chain" field.
If you are creating it from the command line or using the API, then when you create the SSL certificate you have to specify the "CA Bundle" contents in the "Certificate Chain" parameter.
Right now, what you probably have to do is to create a new ELB specifying the right paramenters, modify your DNS accordingly and once the change has been applied, delete the old load balancer.
First you'll need to obtain a copy of the appropriate certificate bundle from your certificate authority.
Then you'll need to update the SSL certificate on your AWS ELB. Select "Upload a new SSL Certificate" from the ELB Select Certificate window. Paste your current private and public certificate keys into the appropriate fields and then paste the certificate bundle into the "Certificate Chain" field.
I have a unique situation where I need to implement client certificate authentication over HTTPS between IE browser and IIS 6. The browser and IIS are separated by a firewall that only allows the browser to connect to IIS on the SSL port.
We have an internal certificate server on the same network as IIS. I've generated an SSL server cert for IIS and that is installed. I configured IIS to only allow SSL, require client certificates.
The limitation here is the browser machine is on a disconnected network, so I can't go to the CA's http://caserver/CertSrv URL and request a client cert like you normally would.
I figured if there were a way that I could generate a CSR against the Root CA's public key, I can copy it to the CA server to generate the client cert. But, there appears to be no provision in IE or the Certificates MMC to do this. The Certificates MMC seems to require a direct connection to the CA.
Has anyone solved this before?
FYI, All servers referenced run Windows Server 2003.
Update: Thanks to Jonas Oberschweiber and Mark Sutton for pointing out the CertReq.exe command line tool. Using this, I've generated a CSR, and consequently a client certificate that installs successfully. However, IE is apparently not sending this client cert when accessing the IIS server in question; it still generates a 403.7 "Forbidden: SSL client certificate is required." I suspect that the reason is that the Subject field of the client cert does not match the user id of the account running IE, thus perhaps not sending a mismatching client cert. The Subject matches that of the user I used to submit the CSR and generate the client cert on the other end of the firewall.
Does the Subject field matter? Is there something else I need to do to enable IE to send this cert?
Use the certreq command on your client as follows
certreq -new -f filein c:\certrequest.req
Here is and example of the filein
[Version]
Signature="$Windows NT$"
[NewRequest]
Subject="CN=dc1.extranet.frbrikam.com"
EncipherOnly = False
Exportable = False
KeyLength = 1024
KeySpec = 1
KeyUsage = 0xA0
MachineKeySet = True
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = CMC
[RequestAttributes]
CertificateTemplate=TLSServer
Replace the CertificateTemplate with the name of your certificate template
Once you have your request file you need to take it to the certificate authority on a usb stick and use the web enrolment interface as usual to process the request file.
Take the output certificate back to the client open it and click install.
You sound like you have already tried a couple of things so my guess is that you are already aware of these, but I'm going to post them anyway, just in case: Certificate Command Line Tools. I am not sure, however, if they do what you want.
Go the http://caserver/CertSrv site that you mentioned using a 3rd computer that can see the CA server. Select the 3rd option, download a CA cert, cert chai, or CRL. On the next page select 'Download CA Certificate Chain', which will download the p7b file. Using a flash drive (or email, etc) transfer this to the other computer which will allow you to import it into the trusted root servers in IE.
http://technet.microsoft.com/en-us/library/cc787796.aspx
Suggestiong for the update, just in case - what is the trusted cert list of in the server?
Subject DN being the same as Windows username has never been a problem for me - although I don't use IIS much. However, somewhere in IIS there is sure to be a trusted certificate list. This error sounds to me like the server's trusted certs list does not include the CA or Root CA that issued the client certificate.
This is particularly true if you never get a certificate selection popup window in IE when you hit the IIS server - even though you have a certificate configured in your IE cert store. That means that the client hit the server, the server gave a list of trusted certs and the client didn't have a cert that fit the list. So the SSL session went to the Forbidden error state.
If the certificate selection window popped up, and you selected and sent the cert, there may be other configuration problems on the server side..