It was a new install. It was already updated.
I did this one time again. Fresh install from FreePBX-32bit-10.13.66.iso. after installing I run āyum updateā too.
so every things and all modules are latest.
I test one time with default certificate.
results:
1-Access to UCP from Firefox via http/s is OK.
2-Access to UCP from Chrome via http/s is NOT ok.
3-User will be registered on https/Firefox but state is UNREACHABLE!
4-When I make a call from webRTC phone, it fails and I receive this in Asterisk:
chan_sip.c:10709 process_sdp: Canāt provide secure audio requested in SDP offer
5-User will be not registered on https/Firefox and I receive this in Asterisk :
ERROR[7191]: tcptls.c:397 tcptls_stream_close: SSL_shutdown() failed: 1
I removed the default certificate and generate a new and add to System admin and even I rebooted my server one time, but the result was same.
maybe FreePBX has kindly behavior with its developers team and this issue happens only for us.
I create a new certificate and import in sysadmin. FAI
I was always told never to run yum update on the FreePBX Distro, and only update the Distro through the following instructions:
I think this issue is only happening for you two or a collective few. The majority seem to have no issues.
Iāve asked before but Iāll ask again. Why donāt you Google how to make a self signed cert and do it manually then upload it through certman. Then we arenāt creating it. You are.
Please focus on one thing at a time. Stop trying to make ucp node or webrtc to work. Focus on getting the certificate to work by itself in all browsers for just the gui part. Stop messing with ucp. Get it to work on the admin side. When you jump around its really hard to help you.
Also stop using 32bit. We are living in 2016 now. The next distro wonāt have a 32bit release.
Ok thanks for advice. Iāll update you very soon about result of these.
Iām installing a 64 bit version and during this I noticed one point that is strange:
if you generate a certificate and assign to one user, if you delete the certificate and generate a new, this certificate not replaced for user, and you should disable webRTC for that user and submit and apply and again enable webRTC for user, submit and apply. (should I report as a bug?)
This solves the making calls from webRTC phone. (http/Firefox)
I made a certificate myself by this command:
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout webserver.key -out webserver.crt
and replaced this two with the files that are used in httpd/ssl.conf
and now I can access to UCP via https/https from FireFox and Chrome. But webRTC phone doesnāt register.
So for first thing: certman is using other method/options for certification generation?
and about second: I donāt receive any traffic from webRTC phone (even any error), how can I debug this?
You need to go into certman and set the certificate you uploaded as the default. Itāll have a green checkmark next to it. Then apply config. Then restart.
dear I did this always.
The bug you reported ( http://issues.freepbx.org/browse/FREEPBX-12617 ) against webrtc is invalid. Iāve checked webrtc with experts (@billsimon) and we donāt have to do the work around youāve listed as itās partially done in the library we use. I still think thereās a major issue with your system
From this and the other few confusing threads on this issue I am gathering that some users are trying to use both http and https in their environments.
@psdk can you use your browserās developer tools to be SURE everything is going over https and wss in your setup?
Sorry. But I did my test with 3 systems, in different environments (network,clients).
Iām confused.
I installed a 64-bit version today. after installation, I updated it to 10.13.66-12 with update script. enable Edge and upgrade all modules to latest.
I made a self-signed certificate and install it in Sysadmin.
Point: My test environment was completely different from other my tests.
Result: I could only login to ucp via https with Firefox, and webRTC phone didnāt register.
I login to ucp via http and webRTC phone registered but I had āUNREACHABLEā issue again.
So please donāt tell me this is my installation issue. this makes me crazy.
Well I am sorry to keep telling you this but I canāt replicate it. My support team canāt. My development team canāt. Other users canāt. I donāt know what you expect us to fix when there is nothing we can figure out.
Perhaps you should consider that we really canāt help you here because of import export laws of cryptographic technologies as well.
The code is open source. So I encourage you to try to figure out the solution yourself. When you do you can post here of course or open a bug but right now we arenāt getting anywhere.
yes youāre right. But please advice me again.
My steps are right?
1-download 64-bit ISO.
2-installed it. (almost my tests are on VMware) and IP from DHCP.
3-after installing and running first boot script I upgrade it to latest version via upgrade script.
4-after finishing this, I reboot the system.
5-access to web
6-activate system
7-enable edge
8-update all modules
9-delete default certificate
10-generate a self-signed
11-import in to Apache with Sysadmin
12-create 2 extensions
13-enable UCP and webRTC for one of them.
and then Iāll test call between them.
I suggest you delete the default CA as well.
yes i did. sorry I wrote bad.
So do you do these steps too?
yes and it works fine.
after yesterday updates, when I login via https to Firefox, I see below errors in Asterisk : (webRTC phoe couldnāt register yet)
[2016-06-30 09:02:33] ERROR[2764]: tcptls.c:609 handle_tcptls_connection: Problem setting up ssl connection: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate
[2016-06-30 09:02:33] WARNING[2764]: tcptls.c:684 handle_tcptls_connection: FILE * open failed!
There were no updates made to anything we have discussed here.
Considering you are coming from Iran. I have no doubt that there are import/export laws specifically prohibiting certain cryptographic technologies from going into your country. Our company is in Canada and the United States, respectively, and thus we really canāt be providing cryptographic support services.