Re: Unable to upload SSL certificate for realhostip replacement
Hi, I’ve fixed cloudmonkey to url encode parameters so now you can use cloudmonkey to upload custom certificate but only in non-interactive mode on shell (bash/zsh). You’ll have to install cloudmonkey from source for now since the fix is only on master. Something like: $ cloudmonkey upload customcertificate id=xx domainsuffix=yy name=zzz certificate=‘asdf asdfasdf asdfasdf asdf---' I’ve some issues to report while replacing certificates to get rid of realhostip, this is specific for Xen could apply for other hypervisors as well: - In case of 4.2, I see in the database that seq is 0 for the root certificate for the realhostip.com domain. I uploaded certificates in order (root, then intermediate and finally SSL cert from UI), and I see the old certificate is still there. after CPVM/SSVM restarts and are in UP state I still get SSL errors and I see that systemvm.iso is not getting patched. How to fix this? Or force systemvm.iso patching? - In case of 4.3.0 and above, I see the same issue. I’m confused whether to use *. wildcard in global setting or not. On 27-Sep-2014, at 9:32 pm, Amogh Vasekar amogh.vase...@citrix.com wrote: Hi, For the encoding, in your case it was the space character causing the issue - it should be replaced by %20. The correct encoding would be (hoping mail clients don't screw up the blob): -BEGIN%20CERTIFICATE-%0AMIIDfTCCAuagAwIBAgIDErvmMA0GCSqGSIb3DQEBBQU AME4xCzAJBgNVBAYTAlVT%0AMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFN lY3VyZSBDZXJ0%0AaWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwNTIxMDQwMDAwWhcNMTgwODIxMDQ wMDAw%0AWjBCMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEbMBkGA1UE%0A AxMSR2VvVHJ1c3QgR2xvYmFsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB%0ACgKCAQEA 2swYYzD99BcjGlZ%2BW988bDjkcbd4kdS8odhM%2BKhDtgPpTSEHCIjaWC9m%0AOSm9BXiLnTjo BbdqfnGk5sRgprDvgOSJKA%2BeJdbtg%2FOtppHHmMlCGDUUna2YRpIu%0AT8rxh0PBFpVXLVDv iS2Aelet8u5fa9IAjbkU%2BBQVNdnARqN7csiRv8lVK83Qlz6c%0AJmTM386DGXHKTubU1XupGc 1V3sjs0l44U%2BVcT4wt%2FlAjNvxm5suOpDkZALeVAjmR%0ACw7%2BOC7RHQWa9k0%2Bbw8HHa 8sHo9gOeL6NlMTOdReJivbPagUvTLrGAMoUgRx5asz%0APeE4uwc2hGKceeoWMPRfwCvocWvk%2 BQIDAQABo4HwMIHtMB8GA1UdIwQYMBaAFEjm%0AaPkr0rKV10fYIyAQTzOYkJ%2FUMB0GA1UdDg QWBBTAephojYn7qwVkDBF9qn1luMrM%0ATjAPBgNVHRMBAf8EBTADAQH%2FMA4GA1UdDwEB%2Fw QEAwIBBjA6BgNVHR8EMzAxMC%2Bg%0ALaArhilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jcmxz L3NlY3VyZWNhLmNybDBO%0ABgNVHSAERzBFMEMGBFUdIAAwOzA5BggrBgEFBQcCARYtaHR0cHM6 Ly93d3cuZ2Vv%0AdHJ1c3QuY29tL3Jlc291cmNlcy9yZXBvc2l0b3J5MA0GCSqGSIb3DQEBBQUA A4GB%0AAHbhEm5OSxYShjAGsoEIz%2FAIx8dxfmbuwu3UOx%2F%2F8PDITtZDOLC5MH0Y0FWDom rL%0ANhGc6Ehmo21%2FuBPUR%2F6LWlxz%2FK7ZGzIZOKuXNBSqltLroxwUCEm2u%2BWR74M26x 1W%0Ab8ravHNjkOR%2Fez4iyz0H7V84dJzjA1BOoa%2BY7mHyhD8S%0A-END%20CERTIFIC ATE- As for the global parameter, you can set it to something like a few seconds and reset to original value when the URLs have been expired. Thanks Amogh On 9/27/14 10:53 AM, Indra Pramana in...@sg.or.id wrote: Hi Wido, I have changed the value of secstorage.ssl.cert.domain and restart management server, before I start uploading all the certificates. I found this article, which might be related to the problem: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Troubleshooting+-+u ploading+custom+domain+certificate+instead+of+using+realhostip.com *Specific Issues seen* 1. Download urls point to the old domain. 1. Reduce the expiration duration of the urls by changing global config extract.url.expiration.interval 2. And change the frequency for cleanup thread through extract.url.cleanup.interval restart MS. 3. Wait for the cleanup thread duration and try downloading again. See whether the url is deleted. 4. DB tables to check (don¹t recommend but worst case) Version 4.2 upload table persists url. Entry is hard deleted on expiration of url. Version = 4.2 template_store_ref, download_url is made null on expiration of url. volume_store_ref, entry hard deleted on expiration of url. But I'm not too sure what is the recommended values I need to set for extract.url.expiration.interval and extract.url.cleanup.interval. Any advise? Thank you. On Sun, Sep 28, 2014 at 1:39 AM, Wido den Hollander w...@widodh.nl wrote: Op 27 sep. 2014 om 19:25 heeft Indra Pramana in...@sg.or.id het volgende geschreven: Dear all, FYI, I managed to complete the tasks and install the certificates. As a workaround to the unable to upload the root/intermediate cert via API issue, I uploaded a certificate with just BEGIN as text via API, and then proceed to update the keystore table on the MySQL database directly to input the whole cert. It seems to be working, after I uploaded the cert and private key via GUI, I can see that both CPVM and SSVM are being restarted. When I test: - Console is working, using my own domain now. Yay! :) - However, when I try to test downloading a template, it's still showing
Re: Unable to upload SSL certificate for realhostip replacement
Just to update on the certificate upload issue with 4.2: I’m able to download and add new volumes/templates/isos and the link provided has a valid https url with the same certificate that I uploaded though when I try to access the console I get SSL cert error and I see that it’s still returning the old *.realhostip.com certificate. I’ve tried to delete old CPVMs and I see the same issue coming up again. On 01-Oct-2014, at 4:55 pm, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, I’ve fixed cloudmonkey to url encode parameters so now you can use cloudmonkey to upload custom certificate but only in non-interactive mode on shell (bash/zsh). You’ll have to install cloudmonkey from source for now since the fix is only on master. Something like: $ cloudmonkey upload customcertificate id=xx domainsuffix=yy name=zzz certificate=‘asdf asdfasdf asdfasdf asdf---' I’ve some issues to report while replacing certificates to get rid of realhostip, this is specific for Xen could apply for other hypervisors as well: - In case of 4.2, I see in the database that seq is 0 for the root certificate for the realhostip.com domain. I uploaded certificates in order (root, then intermediate and finally SSL cert from UI), and I see the old certificate is still there. after CPVM/SSVM restarts and are in UP state I still get SSL errors and I see that systemvm.iso is not getting patched. How to fix this? Or force systemvm.iso patching? - In case of 4.3.0 and above, I see the same issue. I’m confused whether to use *. wildcard in global setting or not. On 27-Sep-2014, at 9:32 pm, Amogh Vasekar amogh.vase...@citrix.com wrote: Hi, For the encoding, in your case it was the space character causing the issue - it should be replaced by %20. The correct encoding would be (hoping mail clients don't screw up the blob): -BEGIN%20CERTIFICATE-%0AMIIDfTCCAuagAwIBAgIDErvmMA0GCSqGSIb3DQEBBQU AME4xCzAJBgNVBAYTAlVT%0AMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFN lY3VyZSBDZXJ0%0AaWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwNTIxMDQwMDAwWhcNMTgwODIxMDQ wMDAw%0AWjBCMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEbMBkGA1UE%0A AxMSR2VvVHJ1c3QgR2xvYmFsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB%0ACgKCAQEA 2swYYzD99BcjGlZ%2BW988bDjkcbd4kdS8odhM%2BKhDtgPpTSEHCIjaWC9m%0AOSm9BXiLnTjo BbdqfnGk5sRgprDvgOSJKA%2BeJdbtg%2FOtppHHmMlCGDUUna2YRpIu%0AT8rxh0PBFpVXLVDv iS2Aelet8u5fa9IAjbkU%2BBQVNdnARqN7csiRv8lVK83Qlz6c%0AJmTM386DGXHKTubU1XupGc 1V3sjs0l44U%2BVcT4wt%2FlAjNvxm5suOpDkZALeVAjmR%0ACw7%2BOC7RHQWa9k0%2Bbw8HHa 8sHo9gOeL6NlMTOdReJivbPagUvTLrGAMoUgRx5asz%0APeE4uwc2hGKceeoWMPRfwCvocWvk%2 BQIDAQABo4HwMIHtMB8GA1UdIwQYMBaAFEjm%0AaPkr0rKV10fYIyAQTzOYkJ%2FUMB0GA1UdDg QWBBTAephojYn7qwVkDBF9qn1luMrM%0ATjAPBgNVHRMBAf8EBTADAQH%2FMA4GA1UdDwEB%2Fw QEAwIBBjA6BgNVHR8EMzAxMC%2Bg%0ALaArhilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jcmxz L3NlY3VyZWNhLmNybDBO%0ABgNVHSAERzBFMEMGBFUdIAAwOzA5BggrBgEFBQcCARYtaHR0cHM6 Ly93d3cuZ2Vv%0AdHJ1c3QuY29tL3Jlc291cmNlcy9yZXBvc2l0b3J5MA0GCSqGSIb3DQEBBQUA A4GB%0AAHbhEm5OSxYShjAGsoEIz%2FAIx8dxfmbuwu3UOx%2F%2F8PDITtZDOLC5MH0Y0FWDom rL%0ANhGc6Ehmo21%2FuBPUR%2F6LWlxz%2FK7ZGzIZOKuXNBSqltLroxwUCEm2u%2BWR74M26x 1W%0Ab8ravHNjkOR%2Fez4iyz0H7V84dJzjA1BOoa%2BY7mHyhD8S%0A-END%20CERTIFIC ATE- As for the global parameter, you can set it to something like a few seconds and reset to original value when the URLs have been expired. Thanks Amogh On 9/27/14 10:53 AM, Indra Pramana in...@sg.or.id wrote: Hi Wido, I have changed the value of secstorage.ssl.cert.domain and restart management server, before I start uploading all the certificates. I found this article, which might be related to the problem: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Troubleshooting+-+u ploading+custom+domain+certificate+instead+of+using+realhostip.com *Specific Issues seen* 1. Download urls point to the old domain. 1. Reduce the expiration duration of the urls by changing global config extract.url.expiration.interval 2. And change the frequency for cleanup thread through extract.url.cleanup.interval restart MS. 3. Wait for the cleanup thread duration and try downloading again. See whether the url is deleted. 4. DB tables to check (don¹t recommend but worst case) Version 4.2 upload table persists url. Entry is hard deleted on expiration of url. Version = 4.2 template_store_ref, download_url is made null on expiration of url. volume_store_ref, entry hard deleted on expiration of url. But I'm not too sure what is the recommended values I need to set for extract.url.expiration.interval and extract.url.cleanup.interval. Any advise? Thank you. On Sun, Sep 28, 2014 at 1:39 AM, Wido den Hollander w...@widodh.nl wrote: Op 27 sep. 2014 om 19:25 heeft Indra Pramana in...@sg.or.id het volgende geschreven: Dear all, FYI, I managed to complete the tasks and install the certificates. As a workaround to the unable to
Re: Unable to upload SSL certificate for realhostip replacement
Hi, For 4.2 you may want to refer here : http://www.chipchilders.com/blog/2013/1/2/undocumented-feature-using-certif icate-chains-in-cloudstack.html 4.3 had a missing commit, due to which the global config consoleproxy.url.domain had to be set to mydomain.com, instead of *.mydomain.com. This has been fixed in 4.3.1 Apologies for the inconvenience. Amogh On 10/1/14 8:16 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Just to update on the certificate upload issue with 4.2: I’m able to download and add new volumes/templates/isos and the link provided has a valid https url with the same certificate that I uploaded though when I try to access the console I get SSL cert error and I see that it’s still returning the old *.realhostip.com certificate. I’ve tried to delete old CPVMs and I see the same issue coming up again. On 01-Oct-2014, at 4:55 pm, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, I’ve fixed cloudmonkey to url encode parameters so now you can use cloudmonkey to upload custom certificate but only in non-interactive mode on shell (bash/zsh). You’ll have to install cloudmonkey from source for now since the fix is only on master. Something like: $ cloudmonkey upload customcertificate id=xx domainsuffix=yy name=zzz certificate=‘asdf asdfasdf asdfasdf asdf---' I’ve some issues to report while replacing certificates to get rid of realhostip, this is specific for Xen could apply for other hypervisors as well: - In case of 4.2, I see in the database that seq is 0 for the root certificate for the realhostip.com domain. I uploaded certificates in order (root, then intermediate and finally SSL cert from UI), and I see the old certificate is still there. after CPVM/SSVM restarts and are in UP state I still get SSL errors and I see that systemvm.iso is not getting patched. How to fix this? Or force systemvm.iso patching? - In case of 4.3.0 and above, I see the same issue. I’m confused whether to use *. wildcard in global setting or not. On 27-Sep-2014, at 9:32 pm, Amogh Vasekar amogh.vase...@citrix.com wrote: Hi, For the encoding, in your case it was the space character causing the issue - it should be replaced by %20. The correct encoding would be (hoping mail clients don't screw up the blob): -BEGIN%20CERTIFICATE-%0AMIIDfTCCAuagAwIBAgIDErvmMA0GCSqGSIb3DQEB BQU AME4xCzAJBgNVBAYTAlVT%0AMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4 IFN lY3VyZSBDZXJ0%0AaWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwNTIxMDQwMDAwWhcNMTgwODIx MDQ wMDAw%0AWjBCMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEbMBkGA1UE %0A AxMSR2VvVHJ1c3QgR2xvYmFsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB%0ACgKCA QEA 2swYYzD99BcjGlZ%2BW988bDjkcbd4kdS8odhM%2BKhDtgPpTSEHCIjaWC9m%0AOSm9BXiLn Tjo BbdqfnGk5sRgprDvgOSJKA%2BeJdbtg%2FOtppHHmMlCGDUUna2YRpIu%0AT8rxh0PBFpVXL VDv iS2Aelet8u5fa9IAjbkU%2BBQVNdnARqN7csiRv8lVK83Qlz6c%0AJmTM386DGXHKTubU1Xu pGc 1V3sjs0l44U%2BVcT4wt%2FlAjNvxm5suOpDkZALeVAjmR%0ACw7%2BOC7RHQWa9k0%2Bbw8 HHa 8sHo9gOeL6NlMTOdReJivbPagUvTLrGAMoUgRx5asz%0APeE4uwc2hGKceeoWMPRfwCvocWv k%2 BQIDAQABo4HwMIHtMB8GA1UdIwQYMBaAFEjm%0AaPkr0rKV10fYIyAQTzOYkJ%2FUMB0GA1U dDg QWBBTAephojYn7qwVkDBF9qn1luMrM%0ATjAPBgNVHRMBAf8EBTADAQH%2FMA4GA1UdDwEB% 2Fw QEAwIBBjA6BgNVHR8EMzAxMC%2Bg%0ALaArhilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jc mxz L3NlY3VyZWNhLmNybDBO%0ABgNVHSAERzBFMEMGBFUdIAAwOzA5BggrBgEFBQcCARYtaHR0c HM6 Ly93d3cuZ2Vv%0AdHJ1c3QuY29tL3Jlc291cmNlcy9yZXBvc2l0b3J5MA0GCSqGSIb3DQEBB QUA A4GB%0AAHbhEm5OSxYShjAGsoEIz%2FAIx8dxfmbuwu3UOx%2F%2F8PDITtZDOLC5MH0Y0FW Dom rL%0ANhGc6Ehmo21%2FuBPUR%2F6LWlxz%2FK7ZGzIZOKuXNBSqltLroxwUCEm2u%2BWR74M 26x 1W%0Ab8ravHNjkOR%2Fez4iyz0H7V84dJzjA1BOoa%2BY7mHyhD8S%0A-END%20CERTI FIC ATE- As for the global parameter, you can set it to something like a few seconds and reset to original value when the URLs have been expired. Thanks Amogh On 9/27/14 10:53 AM, Indra Pramana in...@sg.or.id wrote: Hi Wido, I have changed the value of secstorage.ssl.cert.domain and restart management server, before I start uploading all the certificates. I found this article, which might be related to the problem: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Troubleshooting+ -+u ploading+custom+domain+certificate+instead+of+using+realhostip.com *Specific Issues seen* 1. Download urls point to the old domain. 1. Reduce the expiration duration of the urls by changing global config extract.url.expiration.interval 2. And change the frequency for cleanup thread through extract.url.cleanup.interval restart MS. 3. Wait for the cleanup thread duration and try downloading again. See whether the url is deleted. 4. DB tables to check (don¹t recommend but worst case) Version 4.2 upload table persists url. Entry is hard deleted on expiration of url. Version = 4.2 template_store_ref, download_url is made null on expiration of url. volume_store_ref, entry hard deleted on expiration of url. But I'm not too
Re: Unable to upload SSL certificate for realhostip replacement
Hi Amogh, I’ve a different issue, CPVM is opening the console but the HTTP service is returning old *.realhostip.com certificate. I debugged CPVM agent to find that it’s not picking up the keystore sent from Management server. This issue is like: https://issues.apache.org/jira/browse/CLOUDSTACK-3438 In the logs (from CPVM), I’m only seeing Initializing SSL from built-in default certificate”. Reading source from ConsoleProxySecureServerFactoryImpl, this means the agent is starting but is not getting any StartConsoleProxyAgentHttpHandlerCommand with new KeyStore data. I’ve tested this only for 4.2, Paul suggests something similar for 4.3 as well. I’ve one root certificate (id=1), two intermediate certificate (id=2, id=3) and a wildcard domain cert+key. I uploaded them one by one as per the docs and also following Chip’s blog. By doing so, the SSVM keys got updated and by downloading an ISO I see the https url it gave returned correct SSL certificate which means the chain of certificates etc. worked. In case of CPVM, accessing console in browser led to SSL error. Do you may any suggestions on how to get this fixed? If I remove CPVMs, I see it’s still using old systemvm.iso and though docs/wiki recommend systemvm.iso will get patched, it does not actually. On 01-Oct-2014, at 6:32 pm, Amogh Vasekar amogh.vase...@citrix.com wrote: Hi, For 4.2 you may want to refer here : http://www.chipchilders.com/blog/2013/1/2/undocumented-feature-using-certif icate-chains-in-cloudstack.html 4.3 had a missing commit, due to which the global config consoleproxy.url.domain had to be set to mydomain.com, instead of *.mydomain.com. This has been fixed in 4.3.1 Apologies for the inconvenience. Amogh On 10/1/14 8:16 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Just to update on the certificate upload issue with 4.2: I’m able to download and add new volumes/templates/isos and the link provided has a valid https url with the same certificate that I uploaded though when I try to access the console I get SSL cert error and I see that it’s still returning the old *.realhostip.com certificate. I’ve tried to delete old CPVMs and I see the same issue coming up again. On 01-Oct-2014, at 4:55 pm, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, I’ve fixed cloudmonkey to url encode parameters so now you can use cloudmonkey to upload custom certificate but only in non-interactive mode on shell (bash/zsh). You’ll have to install cloudmonkey from source for now since the fix is only on master. Something like: $ cloudmonkey upload customcertificate id=xx domainsuffix=yy name=zzz certificate=‘asdf asdfasdf asdfasdf asdf---' I’ve some issues to report while replacing certificates to get rid of realhostip, this is specific for Xen could apply for other hypervisors as well: - In case of 4.2, I see in the database that seq is 0 for the root certificate for the realhostip.com domain. I uploaded certificates in order (root, then intermediate and finally SSL cert from UI), and I see the old certificate is still there. after CPVM/SSVM restarts and are in UP state I still get SSL errors and I see that systemvm.iso is not getting patched. How to fix this? Or force systemvm.iso patching? - In case of 4.3.0 and above, I see the same issue. I’m confused whether to use *. wildcard in global setting or not. On 27-Sep-2014, at 9:32 pm, Amogh Vasekar amogh.vase...@citrix.com wrote: Hi, For the encoding, in your case it was the space character causing the issue - it should be replaced by %20. The correct encoding would be (hoping mail clients don't screw up the blob): -BEGIN%20CERTIFICATE-%0AMIIDfTCCAuagAwIBAgIDErvmMA0GCSqGSIb3DQEB BQU AME4xCzAJBgNVBAYTAlVT%0AMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4 IFN lY3VyZSBDZXJ0%0AaWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwNTIxMDQwMDAwWhcNMTgwODIx MDQ wMDAw%0AWjBCMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEbMBkGA1UE %0A AxMSR2VvVHJ1c3QgR2xvYmFsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB%0ACgKCA QEA 2swYYzD99BcjGlZ%2BW988bDjkcbd4kdS8odhM%2BKhDtgPpTSEHCIjaWC9m%0AOSm9BXiLn Tjo BbdqfnGk5sRgprDvgOSJKA%2BeJdbtg%2FOtppHHmMlCGDUUna2YRpIu%0AT8rxh0PBFpVXL VDv iS2Aelet8u5fa9IAjbkU%2BBQVNdnARqN7csiRv8lVK83Qlz6c%0AJmTM386DGXHKTubU1Xu pGc 1V3sjs0l44U%2BVcT4wt%2FlAjNvxm5suOpDkZALeVAjmR%0ACw7%2BOC7RHQWa9k0%2Bbw8 HHa 8sHo9gOeL6NlMTOdReJivbPagUvTLrGAMoUgRx5asz%0APeE4uwc2hGKceeoWMPRfwCvocWv k%2 BQIDAQABo4HwMIHtMB8GA1UdIwQYMBaAFEjm%0AaPkr0rKV10fYIyAQTzOYkJ%2FUMB0GA1U dDg QWBBTAephojYn7qwVkDBF9qn1luMrM%0ATjAPBgNVHRMBAf8EBTADAQH%2FMA4GA1UdDwEB% 2Fw QEAwIBBjA6BgNVHR8EMzAxMC%2Bg%0ALaArhilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jc mxz L3NlY3VyZWNhLmNybDBO%0ABgNVHSAERzBFMEMGBFUdIAAwOzA5BggrBgEFBQcCARYtaHR0c HM6 Ly93d3cuZ2Vv%0AdHJ1c3QuY29tL3Jlc291cmNlcy9yZXBvc2l0b3J5MA0GCSqGSIb3DQEBB QUA A4GB%0AAHbhEm5OSxYShjAGsoEIz%2FAIx8dxfmbuwu3UOx%2F%2F8PDITtZDOLC5MH0Y0FW Dom
Re: Unable to upload SSL certificate for realhostip replacement
Hi, Can you please paste the contents of the keystore table (minus the private key of course)? For SSVM, in 4.2, the certificate chain was not configured correctly and it would only use the server certificate when configuring Apache. It did not impact functionality though. This is not true for CPVM, which would try to use the full chain. It was fixed in 4.3, along with removing a double decoding of certificate when uploaded through API. The double decoding issue would manifest as non-server certificates to be saved incorrectly in the DB, and hence wanted to take a look at the table's contents. Since CPVM uses the full chain but not SSVM, I suspect this might be your issue. For the systemvm.iso - did you rebuild the ISO from source? It gets patched automatically in 4.3 for XS, but 4.2 had a versioning issue due to which it didn't change automatically. For KVM, the ISO gets patched when you reinstall the agent package. For Vmware, one needs to remove the old ISO from secondary storage folder (under path_to_secstorage/systemvm/ I think) so that the new one gets applied. HTH Amogh On 10/1/14 9:51 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi Amogh, I’ve a different issue, CPVM is opening the console but the HTTP service is returning old *.realhostip.com certificate. I debugged CPVM agent to find that it’s not picking up the keystore sent from Management server. This issue is like: https://issues.apache.org/jira/browse/CLOUDSTACK-3438 In the logs (from CPVM), I’m only seeing Initializing SSL from built-in default certificate”. Reading source from ConsoleProxySecureServerFactoryImpl, this means the agent is starting but is not getting any StartConsoleProxyAgentHttpHandlerCommand with new KeyStore data. I’ve tested this only for 4.2, Paul suggests something similar for 4.3 as well. I’ve one root certificate (id=1), two intermediate certificate (id=2, id=3) and a wildcard domain cert+key. I uploaded them one by one as per the docs and also following Chip’s blog. By doing so, the SSVM keys got updated and by downloading an ISO I see the https url it gave returned correct SSL certificate which means the chain of certificates etc. worked. In case of CPVM, accessing console in browser led to SSL error. Do you may any suggestions on how to get this fixed? If I remove CPVMs, I see it’s still using old systemvm.iso and though docs/wiki recommend systemvm.iso will get patched, it does not actually. On 01-Oct-2014, at 6:32 pm, Amogh Vasekar amogh.vase...@citrix.com wrote: Hi, For 4.2 you may want to refer here : http://www.chipchilders.com/blog/2013/1/2/undocumented-feature-using-cert if icate-chains-in-cloudstack.html 4.3 had a missing commit, due to which the global config consoleproxy.url.domain had to be set to mydomain.com, instead of *.mydomain.com. This has been fixed in 4.3.1 Apologies for the inconvenience. Amogh On 10/1/14 8:16 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Just to update on the certificate upload issue with 4.2: I’m able to download and add new volumes/templates/isos and the link provided has a valid https url with the same certificate that I uploaded though when I try to access the console I get SSL cert error and I see that it’s still returning the old *.realhostip.com certificate. I’ve tried to delete old CPVMs and I see the same issue coming up again. On 01-Oct-2014, at 4:55 pm, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, I’ve fixed cloudmonkey to url encode parameters so now you can use cloudmonkey to upload custom certificate but only in non-interactive mode on shell (bash/zsh). You’ll have to install cloudmonkey from source for now since the fix is only on master. Something like: $ cloudmonkey upload customcertificate id=xx domainsuffix=yy name=zzz certificate=‘asdf asdfasdf asdfasdf asdf---' I’ve some issues to report while replacing certificates to get rid of realhostip, this is specific for Xen could apply for other hypervisors as well: - In case of 4.2, I see in the database that seq is 0 for the root certificate for the realhostip.com domain. I uploaded certificates in order (root, then intermediate and finally SSL cert from UI), and I see the old certificate is still there. after CPVM/SSVM restarts and are in UP state I still get SSL errors and I see that systemvm.iso is not getting patched. How to fix this? Or force systemvm.iso patching? - In case of 4.3.0 and above, I see the same issue. I’m confused whether to use *. wildcard in global setting or not. On 27-Sep-2014, at 9:32 pm, Amogh Vasekar amogh.vase...@citrix.com wrote: Hi, For the encoding, in your case it was the space character causing the issue - it should be replaced by %20. The correct encoding would be (hoping mail clients don't screw up the blob): -BEGIN%20CERTIFICATE-%0AMIIDfTCCAuagAwIBAgIDErvmMA0GCSqGSIb3DQ EB BQU AME4xCzAJBgNVBAYTAlVT%0AMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZm F4 IFN
RE: Unable to upload SSL certificate for realhostip replacement
I'm using 4.3.0 with VMware, /usr/share/cloudstack-common/vms/systemvm.iso isn't being updated so removing path_to_secstorage/systemvm/ systemvm-4.3.0.iso just means the original iso get copied back. Regards Paul Angus Cloud Architect S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus paul.an...@shapeblue.com -Original Message- From: Amogh Vasekar [mailto:amogh.vase...@citrix.com] Sent: 01 October 2014 18:15 To: users@cloudstack.apache.org Cc: d...@cloudstack.apache.org Subject: Re: Unable to upload SSL certificate for realhostip replacement Hi, Can you please paste the contents of the keystore table (minus the private key of course)? For SSVM, in 4.2, the certificate chain was not configured correctly and it would only use the server certificate when configuring Apache. It did not impact functionality though. This is not true for CPVM, which would try to use the full chain. It was fixed in 4.3, along with removing a double decoding of certificate when uploaded through API. The double decoding issue would manifest as non-server certificates to be saved incorrectly in the DB, and hence wanted to take a look at the table's contents. Since CPVM uses the full chain but not SSVM, I suspect this might be your issue. For the systemvm.iso - did you rebuild the ISO from source? It gets patched automatically in 4.3 for XS, but 4.2 had a versioning issue due to which it didn't change automatically. For KVM, the ISO gets patched when you reinstall the agent package. For Vmware, one needs to remove the old ISO from secondary storage folder (under path_to_secstorage/systemvm/ I think) so that the new one gets applied. HTH Amogh On 10/1/14 9:51 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi Amogh, I’ve a different issue, CPVM is opening the console but the HTTP service is returning old *.realhostip.com certificate. I debugged CPVM agent to find that it’s not picking up the keystore sent from Management server. This issue is like: https://issues.apache.org/jira/browse/CLOUDSTACK-3438 In the logs (from CPVM), I’m only seeing Initializing SSL from built-in default certificate”. Reading source from ConsoleProxySecureServerFactoryImpl, this means the agent is starting but is not getting any StartConsoleProxyAgentHttpHandlerCommand with new KeyStore data. I’ve tested this only for 4.2, Paul suggests something similar for 4.3 as well. I’ve one root certificate (id=1), two intermediate certificate (id=2, id=3) and a wildcard domain cert+key. I uploaded them one by one as per the docs and also following Chip’s blog. By doing so, the SSVM keys got updated and by downloading an ISO I see the https url it gave returned correct SSL certificate which means the chain of certificates etc. worked. In case of CPVM, accessing console in browser led to SSL error. Do you may any suggestions on how to get this fixed? If I remove CPVMs, I see it’s still using old systemvm.iso and though docs/wiki recommend systemvm.iso will get patched, it does not actually. On 01-Oct-2014, at 6:32 pm, Amogh Vasekar amogh.vase...@citrix.com wrote: Hi, For 4.2 you may want to refer here : http://www.chipchilders.com/blog/2013/1/2/undocumented-feature-using-c ert if icate-chains-in-cloudstack.html 4.3 had a missing commit, due to which the global config consoleproxy.url.domain had to be set to mydomain.com, instead of *.mydomain.com. This has been fixed in 4.3.1 Apologies for the inconvenience. Amogh On 10/1/14 8:16 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Just to update on the certificate upload issue with 4.2: I’m able to download and add new volumes/templates/isos and the link provided has a valid https url with the same certificate that I uploaded though when I try to access the console I get SSL cert error and I see that it’s still returning the old *.realhostip.com certificate. I’ve tried to delete old CPVMs and I see the same issue coming up again. On 01-Oct-2014, at 4:55 pm, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, I’ve fixed cloudmonkey to url encode parameters so now you can use cloudmonkey to upload custom certificate but only in non-interactive mode on shell (bash/zsh). You’ll have to install cloudmonkey from source for now since the fix is only on master. Something like: $ cloudmonkey upload customcertificate id=xx domainsuffix=yy name=zzz certificate=‘asdf asdfasdf asdfasdf asdf---' I’ve some issues to report while replacing certificates to get rid of realhostip, this is specific for Xen could apply for other hypervisors as well: - In case of 4.2, I see in the database that seq is 0 for the root certificate for the realhostip.com domain. I uploaded certificates in order (root, then intermediate and finally SSL cert from UI), and I see the old certificate is still there. after CPVM/SSVM restarts and are in UP state I still get SSL errors and I see that systemvm.iso is not getting patched. How to fix this? Or force systemvm.iso patching
Re: Unable to upload SSL certificate for realhostip replacement
Hi Amogh, Thanks for replying. Here the contents from the keystore table (minus sensitive information): id, name, domain_suffix, seq 1 | CPVMCertificate | custom.domain.com | null 2 | root | realhostip.com | 0 4 | newroot | custom.domain.com | 1 5 | inter1 | custom.domain.com | 2 6 | inter2 | custom.domain.com | 3 The Apache CloudStack version is 4.2.1, the systemvm.iso was built by jenkins.buildacloud.org and it was installed by the built rpms. In my case, the hosts were all XenServer 6.2. I checked the CPVM logs, and I see that it’s not getting keystore bytes[] from Management server at all, so falling back to the default realhostip.keystore file when the AgentShell starts and bootstraps ConsoleProxy. The only issue is when console proxy for a VM is viewed, I’m getting SSL cert error so instead of *.custom.domain.com I get the *.realhostip.com SSL cert. Please suggest how may I debug it further or fix it? On 01-Oct-2014, at 7:15 pm, Amogh Vasekar amogh.vase...@citrix.com wrote: Hi, Can you please paste the contents of the keystore table (minus the private key of course)? For SSVM, in 4.2, the certificate chain was not configured correctly and it would only use the server certificate when configuring Apache. It did not impact functionality though. This is not true for CPVM, which would try to use the full chain. It was fixed in 4.3, along with removing a double decoding of certificate when uploaded through API. The double decoding issue would manifest as non-server certificates to be saved incorrectly in the DB, and hence wanted to take a look at the table's contents. Since CPVM uses the full chain but not SSVM, I suspect this might be your issue. For the systemvm.iso - did you rebuild the ISO from source? It gets patched automatically in 4.3 for XS, but 4.2 had a versioning issue due to which it didn't change automatically. For KVM, the ISO gets patched when you reinstall the agent package. For Vmware, one needs to remove the old ISO from secondary storage folder (under path_to_secstorage/systemvm/ I think) so that the new one gets applied. HTH Amogh On 10/1/14 9:51 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi Amogh, I’ve a different issue, CPVM is opening the console but the HTTP service is returning old *.realhostip.com certificate. I debugged CPVM agent to find that it’s not picking up the keystore sent from Management server. This issue is like: https://issues.apache.org/jira/browse/CLOUDSTACK-3438 In the logs (from CPVM), I’m only seeing Initializing SSL from built-in default certificate”. Reading source from ConsoleProxySecureServerFactoryImpl, this means the agent is starting but is not getting any StartConsoleProxyAgentHttpHandlerCommand with new KeyStore data. I’ve tested this only for 4.2, Paul suggests something similar for 4.3 as well. I’ve one root certificate (id=1), two intermediate certificate (id=2, id=3) and a wildcard domain cert+key. I uploaded them one by one as per the docs and also following Chip’s blog. By doing so, the SSVM keys got updated and by downloading an ISO I see the https url it gave returned correct SSL certificate which means the chain of certificates etc. worked. In case of CPVM, accessing console in browser led to SSL error. Do you may any suggestions on how to get this fixed? If I remove CPVMs, I see it’s still using old systemvm.iso and though docs/wiki recommend systemvm.iso will get patched, it does not actually. On 01-Oct-2014, at 6:32 pm, Amogh Vasekar amogh.vase...@citrix.com wrote: Hi, For 4.2 you may want to refer here : http://www.chipchilders.com/blog/2013/1/2/undocumented-feature-using-cert if icate-chains-in-cloudstack.html 4.3 had a missing commit, due to which the global config consoleproxy.url.domain had to be set to mydomain.com, instead of *.mydomain.com. This has been fixed in 4.3.1 Apologies for the inconvenience. Amogh On 10/1/14 8:16 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Just to update on the certificate upload issue with 4.2: I’m able to download and add new volumes/templates/isos and the link provided has a valid https url with the same certificate that I uploaded though when I try to access the console I get SSL cert error and I see that it’s still returning the old *.realhostip.com certificate. I’ve tried to delete old CPVMs and I see the same issue coming up again. On 01-Oct-2014, at 4:55 pm, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, I’ve fixed cloudmonkey to url encode parameters so now you can use cloudmonkey to upload custom certificate but only in non-interactive mode on shell (bash/zsh). You’ll have to install cloudmonkey from source for now since the fix is only on master. Something like: $ cloudmonkey upload customcertificate id=xx domainsuffix=yy name=zzz certificate=‘asdf asdfasdf asdfasdf asdf---' I’ve some issues to report while replacing certificates to get rid of realhostip, this is
Re: Unable to upload SSL certificate for realhostip replacement
Hi Amogh, Thanks for pointing in the direction of checking the keystore table. I found a certificate entry the content of which was in bad PEM format (newline errors, url encode error I think), the other certs were uploaded using a patched CloudMonkey (fix went today into master) which would url encoded args before sending them to CloudStack. On 01-Oct-2014, at 8:56 pm, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi Amogh, Thanks for replying. Here the contents from the keystore table (minus sensitive information): id, name, domain_suffix, seq 1 | CPVMCertificate | custom.domain.com | null 2 | root | realhostip.com | 0 4 | newroot | custom.domain.com | 1 5 | inter1 | custom.domain.com | 2 6 | inter2 | custom.domain.com | 3 The Apache CloudStack version is 4.2.1, the systemvm.iso was built by jenkins.buildacloud.org and it was installed by the built rpms. In my case, the hosts were all XenServer 6.2. I checked the CPVM logs, and I see that it’s not getting keystore bytes[] from Management server at all, so falling back to the default realhostip.keystore file when the AgentShell starts and bootstraps ConsoleProxy. The only issue is when console proxy for a VM is viewed, I’m getting SSL cert error so instead of *.custom.domain.com I get the *.realhostip.com SSL cert. Please suggest how may I debug it further or fix it? On 01-Oct-2014, at 7:15 pm, Amogh Vasekar amogh.vase...@citrix.com wrote: Hi, Can you please paste the contents of the keystore table (minus the private key of course)? For SSVM, in 4.2, the certificate chain was not configured correctly and it would only use the server certificate when configuring Apache. It did not impact functionality though. This is not true for CPVM, which would try to use the full chain. It was fixed in 4.3, along with removing a double decoding of certificate when uploaded through API. The double decoding issue would manifest as non-server certificates to be saved incorrectly in the DB, and hence wanted to take a look at the table's contents. Since CPVM uses the full chain but not SSVM, I suspect this might be your issue. For the systemvm.iso - did you rebuild the ISO from source? It gets patched automatically in 4.3 for XS, but 4.2 had a versioning issue due to which it didn't change automatically. For KVM, the ISO gets patched when you reinstall the agent package. For Vmware, one needs to remove the old ISO from secondary storage folder (under path_to_secstorage/systemvm/ I think) so that the new one gets applied. HTH Amogh On 10/1/14 9:51 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi Amogh, I’ve a different issue, CPVM is opening the console but the HTTP service is returning old *.realhostip.com certificate. I debugged CPVM agent to find that it’s not picking up the keystore sent from Management server. This issue is like: https://issues.apache.org/jira/browse/CLOUDSTACK-3438 In the logs (from CPVM), I’m only seeing Initializing SSL from built-in default certificate”. Reading source from ConsoleProxySecureServerFactoryImpl, this means the agent is starting but is not getting any StartConsoleProxyAgentHttpHandlerCommand with new KeyStore data. I’ve tested this only for 4.2, Paul suggests something similar for 4.3 as well. I’ve one root certificate (id=1), two intermediate certificate (id=2, id=3) and a wildcard domain cert+key. I uploaded them one by one as per the docs and also following Chip’s blog. By doing so, the SSVM keys got updated and by downloading an ISO I see the https url it gave returned correct SSL certificate which means the chain of certificates etc. worked. In case of CPVM, accessing console in browser led to SSL error. Do you may any suggestions on how to get this fixed? If I remove CPVMs, I see it’s still using old systemvm.iso and though docs/wiki recommend systemvm.iso will get patched, it does not actually. On 01-Oct-2014, at 6:32 pm, Amogh Vasekar amogh.vase...@citrix.com wrote: Hi, For 4.2 you may want to refer here : http://www.chipchilders.com/blog/2013/1/2/undocumented-feature-using-cert if icate-chains-in-cloudstack.html 4.3 had a missing commit, due to which the global config consoleproxy.url.domain had to be set to mydomain.com, instead of *.mydomain.com. This has been fixed in 4.3.1 Apologies for the inconvenience. Amogh On 10/1/14 8:16 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Just to update on the certificate upload issue with 4.2: I’m able to download and add new volumes/templates/isos and the link provided has a valid https url with the same certificate that I uploaded though when I try to access the console I get SSL cert error and I see that it’s still returning the old *.realhostip.com certificate. I’ve tried to delete old CPVMs and I see the same issue coming up again. On 01-Oct-2014, at 4:55 pm, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, I’ve fixed cloudmonkey to url encode
Re: Unable to upload SSL certificate for realhostip replacement
Just an FYI - For troubleshooting in this area do refer to https://cwiki.apache.org/confluence/display/CLOUDSTACK/Troubleshooting+-+up loading+custom+domain+certificate+instead+of+using+realhostip.com Thanks, -Nitin On 01/10/14 12:17 PM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi Amogh, Thanks for pointing in the direction of checking the keystore table. I found a certificate entry the content of which was in bad PEM format (newline errors, url encode error I think), the other certs were uploaded using a patched CloudMonkey (fix went today into master) which would url encoded args before sending them to CloudStack. On 01-Oct-2014, at 8:56 pm, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi Amogh, Thanks for replying. Here the contents from the keystore table (minus sensitive information): id, name, domain_suffix, seq 1 | CPVMCertificate | custom.domain.com | null 2 | root | realhostip.com | 0 4 | newroot | custom.domain.com | 1 5 | inter1 | custom.domain.com | 2 6 | inter2 | custom.domain.com | 3 The Apache CloudStack version is 4.2.1, the systemvm.iso was built by jenkins.buildacloud.org and it was installed by the built rpms. In my case, the hosts were all XenServer 6.2. I checked the CPVM logs, and I see that it’s not getting keystore bytes[] from Management server at all, so falling back to the default realhostip.keystore file when the AgentShell starts and bootstraps ConsoleProxy. The only issue is when console proxy for a VM is viewed, I’m getting SSL cert error so instead of *.custom.domain.com I get the *.realhostip.com SSL cert. Please suggest how may I debug it further or fix it? On 01-Oct-2014, at 7:15 pm, Amogh Vasekar amogh.vase...@citrix.com wrote: Hi, Can you please paste the contents of the keystore table (minus the private key of course)? For SSVM, in 4.2, the certificate chain was not configured correctly and it would only use the server certificate when configuring Apache. It did not impact functionality though. This is not true for CPVM, which would try to use the full chain. It was fixed in 4.3, along with removing a double decoding of certificate when uploaded through API. The double decoding issue would manifest as non-server certificates to be saved incorrectly in the DB, and hence wanted to take a look at the table's contents. Since CPVM uses the full chain but not SSVM, I suspect this might be your issue. For the systemvm.iso - did you rebuild the ISO from source? It gets patched automatically in 4.3 for XS, but 4.2 had a versioning issue due to which it didn't change automatically. For KVM, the ISO gets patched when you reinstall the agent package. For Vmware, one needs to remove the old ISO from secondary storage folder (under path_to_secstorage/systemvm/ I think) so that the new one gets applied. HTH Amogh On 10/1/14 9:51 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi Amogh, I’ve a different issue, CPVM is opening the console but the HTTP service is returning old *.realhostip.com certificate. I debugged CPVM agent to find that it’s not picking up the keystore sent from Management server. This issue is like: https://issues.apache.org/jira/browse/CLOUDSTACK-3438 In the logs (from CPVM), I’m only seeing Initializing SSL from built-in default certificate”. Reading source from ConsoleProxySecureServerFactoryImpl, this means the agent is starting but is not getting any StartConsoleProxyAgentHttpHandlerCommand with new KeyStore data. I’ve tested this only for 4.2, Paul suggests something similar for 4.3 as well. I’ve one root certificate (id=1), two intermediate certificate (id=2, id=3) and a wildcard domain cert+key. I uploaded them one by one as per the docs and also following Chip’s blog. By doing so, the SSVM keys got updated and by downloading an ISO I see the https url it gave returned correct SSL certificate which means the chain of certificates etc. worked. In case of CPVM, accessing console in browser led to SSL error. Do you may any suggestions on how to get this fixed? If I remove CPVMs, I see it’s still using old systemvm.iso and though docs/wiki recommend systemvm.iso will get patched, it does not actually. On 01-Oct-2014, at 6:32 pm, Amogh Vasekar amogh.vase...@citrix.com wrote: Hi, For 4.2 you may want to refer here : http://www.chipchilders.com/blog/2013/1/2/undocumented-feature-using-c ert if icate-chains-in-cloudstack.html 4.3 had a missing commit, due to which the global config consoleproxy.url.domain had to be set to mydomain.com, instead of *.mydomain.com. This has been fixed in 4.3.1 Apologies for the inconvenience. Amogh On 10/1/14 8:16 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Just to update on the certificate upload issue with 4.2: I’m able to download and add new volumes/templates/isos and the link provided has a valid https url with the same certificate that I uploaded though when I try to access the console I get SSL cert error and I see
Re: Unable to upload SSL certificate for realhostip replacement
Thanks Nitin, On 01-Oct-2014, at 10:06 pm, Nitin Mehta nitin.me...@citrix.com wrote: Just an FYI - For troubleshooting in this area do refer to https://cwiki.apache.org/confluence/display/CLOUDSTACK/Troubleshooting+-+up loading+custom+domain+certificate+instead+of+using+realhostip.com I actually read this wiki a couple of times before emailing. The issue was that I used the Chrome Advanced REST client extension as recommended in the docs/wiki and somehow it did not work for me, and it was difficult to use as well. So, I just fixed cloudmonkey to do url encoding of args and used it for all certificates except for one intermediate certificate which was the issue. Thanks. Regards, Rohit Yadav Software Architect, ShapeBlue M. +41 779015219 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: Unable to upload SSL certificate for realhostip replacement
Hi Amogh, I tried again tonight, still the same. Not too sure why, is it something wrong with the certificate? But I have confirmed that it's the correct root certificate from my CA. Any other advice? Looking forward to your reply, thank you. Cheers. On Tue, Sep 23, 2014 at 12:56 AM, Amogh Vasekar amogh.vase...@citrix.com wrote: Can you try using http://meyerweb.com/eric/tools/dencoder/ Amogh On 9/22/14 4:36 AM, Indra Pramana in...@sg.or.id wrote: Dear all, I am following the instruction on this documentation to replace realhostip.com with my own domain. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Procedure+to+Replac e+realhostip.com+with+Your+Own+Domain+Name Everything is fine until I need to upload the root certificate via API. I have URL-encoded the certificate using online URL encoder tool such as: http://www.url-encode-decode.com/ However, when I run the API command, the certificate is rejected, saying that it contains illegal ASCII non-printable characters: for parameter certificate is invalid, contains illegal ASCII non-printable characters I have ensured and verified that it only contains generic ASCII text format, no space, symbol etc. Tried using UTF-8, US-ASCII format while encoding, but still cannot work. Any advice is greatly appreciated. Looking forward to your reply, thank you. Cheers.
Re: Unable to upload SSL certificate for realhostip replacement
Hi Amogh and all, To add, I am using RapidSSL and I got the root and intermediate CAs from here: https://knowledge.rapidssl.com/support/ssl-certificate-support/index?page=contentactp=CROSSLINKid=SO26457 I have ensured that the encoding is done correctly, but still there's issue when I tried to upload it. Is it because I am still using version 4.2.0, may be there's a different method on how to upload? Error messages: uploadcustomcertificateresponse cloud-stack-version=4.2.0 errorcode431/errorcode cserrorcode/cserrorcode errortext Received value -BEGIN CERTIFICATE- MIIDfTCCAuagAwIBAgIDErvmMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVT MRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0 aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwNTIxMDQwMDAwWhcNMTgwODIxMDQwMDAw WjBCMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEbMBkGA1UE AxMSR2VvVHJ1c3QgR2xvYmFsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA2swYYzD99BcjGlZ+W988bDjkcbd4kdS8odhM+KhDtgPpTSEHCIjaWC9m OSm9BXiLnTjoBbdqfnGk5sRgprDvgOSJKA+eJdbtg/OtppHHmMlCGDUUna2YRpIu T8rxh0PBFpVXLVDviS2Aelet8u5fa9IAjbkU+BQVNdnARqN7csiRv8lVK83Qlz6c JmTM386DGXHKTubU1XupGc1V3sjs0l44U+VcT4wt/lAjNvxm5suOpDkZALeVAjmR Cw7+OC7RHQWa9k0+bw8HHa8sHo9gOeL6NlMTOdReJivbPagUvTLrGAMoUgRx5asz PeE4uwc2hGKceeoWMPRfwCvocWvk+QIDAQABo4HwMIHtMB8GA1UdIwQYMBaAFEjm aPkr0rKV10fYIyAQTzOYkJ/UMB0GA1UdDgQWBBTAephojYn7qwVkDBF9qn1luMrM TjAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjA6BgNVHR8EMzAxMC+g LaArhilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jcmxzL3NlY3VyZWNhLmNybDBO BgNVHSAERzBFMEMGBFUdIAAwOzA5BggrBgEFBQcCARYtaHR0cHM6Ly93d3cuZ2Vv dHJ1c3QuY29tL3Jlc291cmNlcy9yZXBvc2l0b3J5MA0GCSqGSIb3DQEBBQUAA4GB AHbhEm5OSxYShjAGsoEIz/AIx8dxfmbuwu3UOx//8PDITtZDOLC5MH0Y0FWDomrL NhGc6Ehmo21/uBPUR/6LWlxz/K7ZGzIZOKuXNBSqltLroxwUCEm2u+WR74M26x1W b8ravHNjkOR/ez4iyz0H7V84dJzjA1BOoa+Y7mHyhD8S -END CERTIFICATE- for parameter certificate is invalid, contains illegal ASCII non-printable characters /errortext /uploadcustomcertificateresponse Any advice is greatly appreciated, since 30 Sep is just another 3 days... On Sat, Sep 27, 2014 at 11:21 PM, Indra Pramana in...@sg.or.id wrote: Hi Amogh, I tried again tonight, still the same. Not too sure why, is it something wrong with the certificate? But I have confirmed that it's the correct root certificate from my CA. Any other advice? Looking forward to your reply, thank you. Cheers. On Tue, Sep 23, 2014 at 12:56 AM, Amogh Vasekar amogh.vase...@citrix.com wrote: Can you try using http://meyerweb.com/eric/tools/dencoder/ Amogh On 9/22/14 4:36 AM, Indra Pramana in...@sg.or.id wrote: Dear all, I am following the instruction on this documentation to replace realhostip.com with my own domain. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Procedure+to+Replac e+realhostip.com+with+Your+Own+Domain+Name Everything is fine until I need to upload the root certificate via API. I have URL-encoded the certificate using online URL encoder tool such as: http://www.url-encode-decode.com/ However, when I run the API command, the certificate is rejected, saying that it contains illegal ASCII non-printable characters: for parameter certificate is invalid, contains illegal ASCII non-printable characters I have ensured and verified that it only contains generic ASCII text format, no space, symbol etc. Tried using UTF-8, US-ASCII format while encoding, but still cannot work. Any advice is greatly appreciated. Looking forward to your reply, thank you. Cheers.
Re: Unable to upload SSL certificate for realhostip replacement
I tried to key in just BEGIN CERTIFICATE\nEND CERTIFICATE without the - and the content of the certificate itself. Same problem persists, it says parameter certificate is invalid, contains illegal ASCII non-printable characters. uploadcustomcertificateresponse cloud-stack-version=4.2.0 errorcode431/errorcode cserrorcode/cserrorcode errortext Received value BEGIN CERTIFICATE END CERTIFICATE for parameter certificate is invalid, contains illegal ASCII non-printable characters /errortext /uploadcustomcertificateresponse Seems the issue was not actually on the certificate itself, but may be on the API call handler? Any advice is greatly appreciated. On Sat, Sep 27, 2014 at 11:35 PM, Indra Pramana in...@sg.or.id wrote: Hi Amogh and all, To add, I am using RapidSSL and I got the root and intermediate CAs from here: https://knowledge.rapidssl.com/support/ssl-certificate-support/index?page=contentactp=CROSSLINKid=SO26457 I have ensured that the encoding is done correctly, but still there's issue when I tried to upload it. Is it because I am still using version 4.2.0, may be there's a different method on how to upload? Error messages: uploadcustomcertificateresponse cloud-stack-version=4.2.0 errorcode431/errorcode cserrorcode/cserrorcode errortext Received value -BEGIN CERTIFICATE- MIIDfTCCAuagAwIBAgIDErvmMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVT MRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0 aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwNTIxMDQwMDAwWhcNMTgwODIxMDQwMDAw WjBCMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEbMBkGA1UE AxMSR2VvVHJ1c3QgR2xvYmFsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA2swYYzD99BcjGlZ+W988bDjkcbd4kdS8odhM+KhDtgPpTSEHCIjaWC9m OSm9BXiLnTjoBbdqfnGk5sRgprDvgOSJKA+eJdbtg/OtppHHmMlCGDUUna2YRpIu T8rxh0PBFpVXLVDviS2Aelet8u5fa9IAjbkU+BQVNdnARqN7csiRv8lVK83Qlz6c JmTM386DGXHKTubU1XupGc1V3sjs0l44U+VcT4wt/lAjNvxm5suOpDkZALeVAjmR Cw7+OC7RHQWa9k0+bw8HHa8sHo9gOeL6NlMTOdReJivbPagUvTLrGAMoUgRx5asz PeE4uwc2hGKceeoWMPRfwCvocWvk+QIDAQABo4HwMIHtMB8GA1UdIwQYMBaAFEjm aPkr0rKV10fYIyAQTzOYkJ/UMB0GA1UdDgQWBBTAephojYn7qwVkDBF9qn1luMrM TjAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjA6BgNVHR8EMzAxMC+g LaArhilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jcmxzL3NlY3VyZWNhLmNybDBO BgNVHSAERzBFMEMGBFUdIAAwOzA5BggrBgEFBQcCARYtaHR0cHM6Ly93d3cuZ2Vv dHJ1c3QuY29tL3Jlc291cmNlcy9yZXBvc2l0b3J5MA0GCSqGSIb3DQEBBQUAA4GB AHbhEm5OSxYShjAGsoEIz/AIx8dxfmbuwu3UOx//8PDITtZDOLC5MH0Y0FWDomrL NhGc6Ehmo21/uBPUR/6LWlxz/K7ZGzIZOKuXNBSqltLroxwUCEm2u+WR74M26x1W b8ravHNjkOR/ez4iyz0H7V84dJzjA1BOoa+Y7mHyhD8S -END CERTIFICATE- for parameter certificate is invalid, contains illegal ASCII non-printable characters /errortext /uploadcustomcertificateresponse Any advice is greatly appreciated, since 30 Sep is just another 3 days... On Sat, Sep 27, 2014 at 11:21 PM, Indra Pramana in...@sg.or.id wrote: Hi Amogh, I tried again tonight, still the same. Not too sure why, is it something wrong with the certificate? But I have confirmed that it's the correct root certificate from my CA. Any other advice? Looking forward to your reply, thank you. Cheers. On Tue, Sep 23, 2014 at 12:56 AM, Amogh Vasekar amogh.vase...@citrix.com wrote: Can you try using http://meyerweb.com/eric/tools/dencoder/ Amogh On 9/22/14 4:36 AM, Indra Pramana in...@sg.or.id wrote: Dear all, I am following the instruction on this documentation to replace realhostip.com with my own domain. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Procedure+to+Replac e+realhostip.com+with+Your+Own+Domain+Name Everything is fine until I need to upload the root certificate via API. I have URL-encoded the certificate using online URL encoder tool such as: http://www.url-encode-decode.com/ However, when I run the API command, the certificate is rejected, saying that it contains illegal ASCII non-printable characters: for parameter certificate is invalid, contains illegal ASCII non-printable characters I have ensured and verified that it only contains generic ASCII text format, no space, symbol etc. Tried using UTF-8, US-ASCII format while encoding, but still cannot work. Any advice is greatly appreciated. Looking forward to your reply, thank you. Cheers.
Re: Unable to upload SSL certificate for realhostip replacement
Only if I key in the certificate as BEGIN, then it seems to be accepting. But of course, the certificate is invalid. uploadcustomcertificateresponse cloud-stack-version=4.2.0 jobid1efe722a-e7c7-4c43-9f6b-67ce860dbe34/jobid /uploadcustomcertificateresponse Is it my browser issue? I have tried using two different browsers: Firefox and Chrome, and both are having the same problem. On Sun, Sep 28, 2014 at 12:36 AM, Indra Pramana in...@sg.or.id wrote: I tried to key in just BEGIN CERTIFICATE\nEND CERTIFICATE without the - and the content of the certificate itself. Same problem persists, it says parameter certificate is invalid, contains illegal ASCII non-printable characters. uploadcustomcertificateresponse cloud-stack-version=4.2.0 errorcode431/errorcode cserrorcode/cserrorcode errortext Received value BEGIN CERTIFICATE END CERTIFICATE for parameter certificate is invalid, contains illegal ASCII non-printable characters /errortext /uploadcustomcertificateresponse Seems the issue was not actually on the certificate itself, but may be on the API call handler? Any advice is greatly appreciated. On Sat, Sep 27, 2014 at 11:35 PM, Indra Pramana in...@sg.or.id wrote: Hi Amogh and all, To add, I am using RapidSSL and I got the root and intermediate CAs from here: https://knowledge.rapidssl.com/support/ssl-certificate-support/index?page=contentactp=CROSSLINKid=SO26457 I have ensured that the encoding is done correctly, but still there's issue when I tried to upload it. Is it because I am still using version 4.2.0, may be there's a different method on how to upload? Error messages: uploadcustomcertificateresponse cloud-stack-version=4.2.0 errorcode431/errorcode cserrorcode/cserrorcode errortext Received value -BEGIN CERTIFICATE- MIIDfTCCAuagAwIBAgIDErvmMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVT MRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0 aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwNTIxMDQwMDAwWhcNMTgwODIxMDQwMDAw WjBCMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEbMBkGA1UE AxMSR2VvVHJ1c3QgR2xvYmFsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA2swYYzD99BcjGlZ+W988bDjkcbd4kdS8odhM+KhDtgPpTSEHCIjaWC9m OSm9BXiLnTjoBbdqfnGk5sRgprDvgOSJKA+eJdbtg/OtppHHmMlCGDUUna2YRpIu T8rxh0PBFpVXLVDviS2Aelet8u5fa9IAjbkU+BQVNdnARqN7csiRv8lVK83Qlz6c JmTM386DGXHKTubU1XupGc1V3sjs0l44U+VcT4wt/lAjNvxm5suOpDkZALeVAjmR Cw7+OC7RHQWa9k0+bw8HHa8sHo9gOeL6NlMTOdReJivbPagUvTLrGAMoUgRx5asz PeE4uwc2hGKceeoWMPRfwCvocWvk+QIDAQABo4HwMIHtMB8GA1UdIwQYMBaAFEjm aPkr0rKV10fYIyAQTzOYkJ/UMB0GA1UdDgQWBBTAephojYn7qwVkDBF9qn1luMrM TjAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjA6BgNVHR8EMzAxMC+g LaArhilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jcmxzL3NlY3VyZWNhLmNybDBO BgNVHSAERzBFMEMGBFUdIAAwOzA5BggrBgEFBQcCARYtaHR0cHM6Ly93d3cuZ2Vv dHJ1c3QuY29tL3Jlc291cmNlcy9yZXBvc2l0b3J5MA0GCSqGSIb3DQEBBQUAA4GB AHbhEm5OSxYShjAGsoEIz/AIx8dxfmbuwu3UOx//8PDITtZDOLC5MH0Y0FWDomrL NhGc6Ehmo21/uBPUR/6LWlxz/K7ZGzIZOKuXNBSqltLroxwUCEm2u+WR74M26x1W b8ravHNjkOR/ez4iyz0H7V84dJzjA1BOoa+Y7mHyhD8S -END CERTIFICATE- for parameter certificate is invalid, contains illegal ASCII non-printable characters /errortext /uploadcustomcertificateresponse Any advice is greatly appreciated, since 30 Sep is just another 3 days... On Sat, Sep 27, 2014 at 11:21 PM, Indra Pramana in...@sg.or.id wrote: Hi Amogh, I tried again tonight, still the same. Not too sure why, is it something wrong with the certificate? But I have confirmed that it's the correct root certificate from my CA. Any other advice? Looking forward to your reply, thank you. Cheers. On Tue, Sep 23, 2014 at 12:56 AM, Amogh Vasekar amogh.vase...@citrix.com wrote: Can you try using http://meyerweb.com/eric/tools/dencoder/ Amogh On 9/22/14 4:36 AM, Indra Pramana in...@sg.or.id wrote: Dear all, I am following the instruction on this documentation to replace realhostip.com with my own domain. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Procedure+to+Replac e+realhostip.com+with+Your+Own+Domain+Name Everything is fine until I need to upload the root certificate via API. I have URL-encoded the certificate using online URL encoder tool such as: http://www.url-encode-decode.com/ However, when I run the API command, the certificate is rejected, saying that it contains illegal ASCII non-printable characters: for parameter certificate is invalid, contains illegal ASCII non-printable characters I have ensured and verified that it only contains generic ASCII text format, no space, symbol etc. Tried using UTF-8, US-ASCII format while encoding, but still cannot work. Any advice is greatly appreciated. Looking forward to your reply, thank you. Cheers.
Re: Unable to upload SSL certificate for realhostip replacement
Dear all, Apologise for sending quite a lot of emails tonight. Anyone knows if it's safe for me to update the keystore table on the database directly? Since the API call doesn't work. Thank you. On Sun, Sep 28, 2014 at 12:39 AM, Indra Pramana in...@sg.or.id wrote: Only if I key in the certificate as BEGIN, then it seems to be accepting. But of course, the certificate is invalid. uploadcustomcertificateresponse cloud-stack-version=4.2.0 jobid1efe722a-e7c7-4c43-9f6b-67ce860dbe34/jobid /uploadcustomcertificateresponse Is it my browser issue? I have tried using two different browsers: Firefox and Chrome, and both are having the same problem. On Sun, Sep 28, 2014 at 12:36 AM, Indra Pramana in...@sg.or.id wrote: I tried to key in just BEGIN CERTIFICATE\nEND CERTIFICATE without the - and the content of the certificate itself. Same problem persists, it says parameter certificate is invalid, contains illegal ASCII non-printable characters. uploadcustomcertificateresponse cloud-stack-version=4.2.0 errorcode431/errorcode cserrorcode/cserrorcode errortext Received value BEGIN CERTIFICATE END CERTIFICATE for parameter certificate is invalid, contains illegal ASCII non-printable characters /errortext /uploadcustomcertificateresponse Seems the issue was not actually on the certificate itself, but may be on the API call handler? Any advice is greatly appreciated. On Sat, Sep 27, 2014 at 11:35 PM, Indra Pramana in...@sg.or.id wrote: Hi Amogh and all, To add, I am using RapidSSL and I got the root and intermediate CAs from here: https://knowledge.rapidssl.com/support/ssl-certificate-support/index?page=contentactp=CROSSLINKid=SO26457 I have ensured that the encoding is done correctly, but still there's issue when I tried to upload it. Is it because I am still using version 4.2.0, may be there's a different method on how to upload? Error messages: uploadcustomcertificateresponse cloud-stack-version=4.2.0 errorcode431/errorcode cserrorcode/cserrorcode errortext Received value -BEGIN CERTIFICATE- MIIDfTCCAuagAwIBAgIDErvmMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVT MRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0 aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwNTIxMDQwMDAwWhcNMTgwODIxMDQwMDAw WjBCMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEbMBkGA1UE AxMSR2VvVHJ1c3QgR2xvYmFsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA2swYYzD99BcjGlZ+W988bDjkcbd4kdS8odhM+KhDtgPpTSEHCIjaWC9m OSm9BXiLnTjoBbdqfnGk5sRgprDvgOSJKA+eJdbtg/OtppHHmMlCGDUUna2YRpIu T8rxh0PBFpVXLVDviS2Aelet8u5fa9IAjbkU+BQVNdnARqN7csiRv8lVK83Qlz6c JmTM386DGXHKTubU1XupGc1V3sjs0l44U+VcT4wt/lAjNvxm5suOpDkZALeVAjmR Cw7+OC7RHQWa9k0+bw8HHa8sHo9gOeL6NlMTOdReJivbPagUvTLrGAMoUgRx5asz PeE4uwc2hGKceeoWMPRfwCvocWvk+QIDAQABo4HwMIHtMB8GA1UdIwQYMBaAFEjm aPkr0rKV10fYIyAQTzOYkJ/UMB0GA1UdDgQWBBTAephojYn7qwVkDBF9qn1luMrM TjAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjA6BgNVHR8EMzAxMC+g LaArhilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jcmxzL3NlY3VyZWNhLmNybDBO BgNVHSAERzBFMEMGBFUdIAAwOzA5BggrBgEFBQcCARYtaHR0cHM6Ly93d3cuZ2Vv dHJ1c3QuY29tL3Jlc291cmNlcy9yZXBvc2l0b3J5MA0GCSqGSIb3DQEBBQUAA4GB AHbhEm5OSxYShjAGsoEIz/AIx8dxfmbuwu3UOx//8PDITtZDOLC5MH0Y0FWDomrL NhGc6Ehmo21/uBPUR/6LWlxz/K7ZGzIZOKuXNBSqltLroxwUCEm2u+WR74M26x1W b8ravHNjkOR/ez4iyz0H7V84dJzjA1BOoa+Y7mHyhD8S -END CERTIFICATE- for parameter certificate is invalid, contains illegal ASCII non-printable characters /errortext /uploadcustomcertificateresponse Any advice is greatly appreciated, since 30 Sep is just another 3 days... On Sat, Sep 27, 2014 at 11:21 PM, Indra Pramana in...@sg.or.id wrote: Hi Amogh, I tried again tonight, still the same. Not too sure why, is it something wrong with the certificate? But I have confirmed that it's the correct root certificate from my CA. Any other advice? Looking forward to your reply, thank you. Cheers. On Tue, Sep 23, 2014 at 12:56 AM, Amogh Vasekar amogh.vase...@citrix.com wrote: Can you try using http://meyerweb.com/eric/tools/dencoder/ Amogh On 9/22/14 4:36 AM, Indra Pramana in...@sg.or.id wrote: Dear all, I am following the instruction on this documentation to replace realhostip.com with my own domain. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Procedure+to+Replac e+realhostip.com+with+Your+Own+Domain+Name Everything is fine until I need to upload the root certificate via API. I have URL-encoded the certificate using online URL encoder tool such as: http://www.url-encode-decode.com/ However, when I run the API command, the certificate is rejected, saying that it contains illegal ASCII non-printable characters: for parameter certificate is invalid, contains illegal ASCII non-printable characters I have ensured and verified that it only contains generic ASCII text format, no space, symbol etc. Tried using UTF-8, US-ASCII format while encoding, but still cannot work. Any advice is greatly appreciated. Looking forward
Re: Unable to upload SSL certificate for realhostip replacement
Dear all, FYI, I managed to complete the tasks and install the certificates. As a workaround to the unable to upload the root/intermediate cert via API issue, I uploaded a certificate with just BEGIN as text via API, and then proceed to update the keystore table on the MySQL database directly to input the whole cert. It seems to be working, after I uploaded the cert and private key via GUI, I can see that both CPVM and SSVM are being restarted. When I test: - Console is working, using my own domain now. Yay! :) - However, when I try to test downloading a template, it's still showing realhostip.com as the URL to download. I have tried destroying the SSVM and a new SSVM was created, up and running. However, it's still showing realhostip.com when I test again. Anyone knows why it's still referring to realhostip.com for downloading templates? Looking forward to your reply, thank you. Cheers. On Sun, Sep 28, 2014 at 12:49 AM, Indra Pramana in...@sg.or.id wrote: Dear all, Apologise for sending quite a lot of emails tonight. Anyone knows if it's safe for me to update the keystore table on the database directly? Since the API call doesn't work. Thank you. On Sun, Sep 28, 2014 at 12:39 AM, Indra Pramana in...@sg.or.id wrote: Only if I key in the certificate as BEGIN, then it seems to be accepting. But of course, the certificate is invalid. uploadcustomcertificateresponse cloud-stack-version=4.2.0 jobid1efe722a-e7c7-4c43-9f6b-67ce860dbe34/jobid /uploadcustomcertificateresponse Is it my browser issue? I have tried using two different browsers: Firefox and Chrome, and both are having the same problem. On Sun, Sep 28, 2014 at 12:36 AM, Indra Pramana in...@sg.or.id wrote: I tried to key in just BEGIN CERTIFICATE\nEND CERTIFICATE without the - and the content of the certificate itself. Same problem persists, it says parameter certificate is invalid, contains illegal ASCII non-printable characters. uploadcustomcertificateresponse cloud-stack-version=4.2.0 errorcode431/errorcode cserrorcode/cserrorcode errortext Received value BEGIN CERTIFICATE END CERTIFICATE for parameter certificate is invalid, contains illegal ASCII non-printable characters /errortext /uploadcustomcertificateresponse Seems the issue was not actually on the certificate itself, but may be on the API call handler? Any advice is greatly appreciated. On Sat, Sep 27, 2014 at 11:35 PM, Indra Pramana in...@sg.or.id wrote: Hi Amogh and all, To add, I am using RapidSSL and I got the root and intermediate CAs from here: https://knowledge.rapidssl.com/support/ssl-certificate-support/index?page=contentactp=CROSSLINKid=SO26457 I have ensured that the encoding is done correctly, but still there's issue when I tried to upload it. Is it because I am still using version 4.2.0, may be there's a different method on how to upload? Error messages: uploadcustomcertificateresponse cloud-stack-version=4.2.0 errorcode431/errorcode cserrorcode/cserrorcode errortext Received value -BEGIN CERTIFICATE- MIIDfTCCAuagAwIBAgIDErvmMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVT MRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0 aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwNTIxMDQwMDAwWhcNMTgwODIxMDQwMDAw WjBCMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEbMBkGA1UE AxMSR2VvVHJ1c3QgR2xvYmFsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA2swYYzD99BcjGlZ+W988bDjkcbd4kdS8odhM+KhDtgPpTSEHCIjaWC9m OSm9BXiLnTjoBbdqfnGk5sRgprDvgOSJKA+eJdbtg/OtppHHmMlCGDUUna2YRpIu T8rxh0PBFpVXLVDviS2Aelet8u5fa9IAjbkU+BQVNdnARqN7csiRv8lVK83Qlz6c JmTM386DGXHKTubU1XupGc1V3sjs0l44U+VcT4wt/lAjNvxm5suOpDkZALeVAjmR Cw7+OC7RHQWa9k0+bw8HHa8sHo9gOeL6NlMTOdReJivbPagUvTLrGAMoUgRx5asz PeE4uwc2hGKceeoWMPRfwCvocWvk+QIDAQABo4HwMIHtMB8GA1UdIwQYMBaAFEjm aPkr0rKV10fYIyAQTzOYkJ/UMB0GA1UdDgQWBBTAephojYn7qwVkDBF9qn1luMrM TjAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjA6BgNVHR8EMzAxMC+g LaArhilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jcmxzL3NlY3VyZWNhLmNybDBO BgNVHSAERzBFMEMGBFUdIAAwOzA5BggrBgEFBQcCARYtaHR0cHM6Ly93d3cuZ2Vv dHJ1c3QuY29tL3Jlc291cmNlcy9yZXBvc2l0b3J5MA0GCSqGSIb3DQEBBQUAA4GB AHbhEm5OSxYShjAGsoEIz/AIx8dxfmbuwu3UOx//8PDITtZDOLC5MH0Y0FWDomrL NhGc6Ehmo21/uBPUR/6LWlxz/K7ZGzIZOKuXNBSqltLroxwUCEm2u+WR74M26x1W b8ravHNjkOR/ez4iyz0H7V84dJzjA1BOoa+Y7mHyhD8S -END CERTIFICATE- for parameter certificate is invalid, contains illegal ASCII non-printable characters /errortext /uploadcustomcertificateresponse Any advice is greatly appreciated, since 30 Sep is just another 3 days... On Sat, Sep 27, 2014 at 11:21 PM, Indra Pramana in...@sg.or.id wrote: Hi Amogh, I tried again tonight, still the same. Not too sure why, is it something wrong with the certificate? But I have confirmed that it's the correct root certificate from my CA. Any other advice? Looking forward to your reply, thank you. Cheers. On Tue, Sep 23, 2014 at 12:56 AM, Amogh Vasekar amogh.vase...@citrix.com wrote: Can you try using
Re: Unable to upload SSL certificate for realhostip replacement
Op 27 sep. 2014 om 19:25 heeft Indra Pramana in...@sg.or.id het volgende geschreven: Dear all, FYI, I managed to complete the tasks and install the certificates. As a workaround to the unable to upload the root/intermediate cert via API issue, I uploaded a certificate with just BEGIN as text via API, and then proceed to update the keystore table on the MySQL database directly to input the whole cert. It seems to be working, after I uploaded the cert and private key via GUI, I can see that both CPVM and SSVM are being restarted. When I test: - Console is working, using my own domain now. Yay! :) - However, when I try to test downloading a template, it's still showing realhostip.com as the URL to download. I have tried destroying the SSVM and a new SSVM was created, up and running. However, it's still showing realhostip.com when I test again. Anyone knows why it's still referring to realhostip.com for downloading templates? Look at the global settings. There is a domain for the sec storage as well. Maybe restart the mgmt server? Looking forward to your reply, thank you. Cheers. On Sun, Sep 28, 2014 at 12:49 AM, Indra Pramana in...@sg.or.id wrote: Dear all, Apologise for sending quite a lot of emails tonight. Anyone knows if it's safe for me to update the keystore table on the database directly? Since the API call doesn't work. Thank you. On Sun, Sep 28, 2014 at 12:39 AM, Indra Pramana in...@sg.or.id wrote: Only if I key in the certificate as BEGIN, then it seems to be accepting. But of course, the certificate is invalid. uploadcustomcertificateresponse cloud-stack-version=4.2.0 jobid1efe722a-e7c7-4c43-9f6b-67ce860dbe34/jobid /uploadcustomcertificateresponse Is it my browser issue? I have tried using two different browsers: Firefox and Chrome, and both are having the same problem. On Sun, Sep 28, 2014 at 12:36 AM, Indra Pramana in...@sg.or.id wrote: I tried to key in just BEGIN CERTIFICATE\nEND CERTIFICATE without the - and the content of the certificate itself. Same problem persists, it says parameter certificate is invalid, contains illegal ASCII non-printable characters. uploadcustomcertificateresponse cloud-stack-version=4.2.0 errorcode431/errorcode cserrorcode/cserrorcode errortext Received value BEGIN CERTIFICATE END CERTIFICATE for parameter certificate is invalid, contains illegal ASCII non-printable characters /errortext /uploadcustomcertificateresponse Seems the issue was not actually on the certificate itself, but may be on the API call handler? Any advice is greatly appreciated. On Sat, Sep 27, 2014 at 11:35 PM, Indra Pramana in...@sg.or.id wrote: Hi Amogh and all, To add, I am using RapidSSL and I got the root and intermediate CAs from here: https://knowledge.rapidssl.com/support/ssl-certificate-support/index?page=contentactp=CROSSLINKid=SO26457 I have ensured that the encoding is done correctly, but still there's issue when I tried to upload it. Is it because I am still using version 4.2.0, may be there's a different method on how to upload? Error messages: uploadcustomcertificateresponse cloud-stack-version=4.2.0 errorcode431/errorcode cserrorcode/cserrorcode errortext Received value -BEGIN CERTIFICATE- MIIDfTCCAuagAwIBAgIDErvmMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVT MRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0 aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwNTIxMDQwMDAwWhcNMTgwODIxMDQwMDAw WjBCMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEbMBkGA1UE AxMSR2VvVHJ1c3QgR2xvYmFsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA2swYYzD99BcjGlZ+W988bDjkcbd4kdS8odhM+KhDtgPpTSEHCIjaWC9m OSm9BXiLnTjoBbdqfnGk5sRgprDvgOSJKA+eJdbtg/OtppHHmMlCGDUUna2YRpIu T8rxh0PBFpVXLVDviS2Aelet8u5fa9IAjbkU+BQVNdnARqN7csiRv8lVK83Qlz6c JmTM386DGXHKTubU1XupGc1V3sjs0l44U+VcT4wt/lAjNvxm5suOpDkZALeVAjmR Cw7+OC7RHQWa9k0+bw8HHa8sHo9gOeL6NlMTOdReJivbPagUvTLrGAMoUgRx5asz PeE4uwc2hGKceeoWMPRfwCvocWvk+QIDAQABo4HwMIHtMB8GA1UdIwQYMBaAFEjm aPkr0rKV10fYIyAQTzOYkJ/UMB0GA1UdDgQWBBTAephojYn7qwVkDBF9qn1luMrM TjAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjA6BgNVHR8EMzAxMC+g LaArhilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jcmxzL3NlY3VyZWNhLmNybDBO BgNVHSAERzBFMEMGBFUdIAAwOzA5BggrBgEFBQcCARYtaHR0cHM6Ly93d3cuZ2Vv dHJ1c3QuY29tL3Jlc291cmNlcy9yZXBvc2l0b3J5MA0GCSqGSIb3DQEBBQUAA4GB AHbhEm5OSxYShjAGsoEIz/AIx8dxfmbuwu3UOx//8PDITtZDOLC5MH0Y0FWDomrL NhGc6Ehmo21/uBPUR/6LWlxz/K7ZGzIZOKuXNBSqltLroxwUCEm2u+WR74M26x1W b8ravHNjkOR/ez4iyz0H7V84dJzjA1BOoa+Y7mHyhD8S -END CERTIFICATE- for parameter certificate is invalid, contains illegal ASCII non-printable characters /errortext /uploadcustomcertificateresponse Any advice is greatly appreciated, since 30 Sep is just another 3 days... On Sat, Sep 27, 2014 at 11:21 PM, Indra Pramana in...@sg.or.id wrote: Hi Amogh, I tried again tonight, still the same. Not too sure why, is it something wrong with the certificate?
Re: Unable to upload SSL certificate for realhostip replacement
Hi Wido, I have changed the value of secstorage.ssl.cert.domain and restart management server, before I start uploading all the certificates. I found this article, which might be related to the problem: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Troubleshooting+-+uploading+custom+domain+certificate+instead+of+using+realhostip.com *Specific Issues seen* 1. Download urls point to the old domain. 1. Reduce the expiration duration of the urls by changing global config extract.url.expiration.interval 2. And change the frequency for cleanup thread through extract.url.cleanup.interval restart MS. 3. Wait for the cleanup thread duration and try downloading again. See whether the url is deleted. 4. DB tables to check (don’t recommend but worst case) Version 4.2 – upload table persists url. Entry is hard deleted on expiration of url. Version = 4.2 – template_store_ref, download_url is made null on expiration of url. volume_store_ref, entry hard deleted on expiration of url. But I'm not too sure what is the recommended values I need to set for extract.url.expiration.interval and extract.url.cleanup.interval. Any advise? Thank you. On Sun, Sep 28, 2014 at 1:39 AM, Wido den Hollander w...@widodh.nl wrote: Op 27 sep. 2014 om 19:25 heeft Indra Pramana in...@sg.or.id het volgende geschreven: Dear all, FYI, I managed to complete the tasks and install the certificates. As a workaround to the unable to upload the root/intermediate cert via API issue, I uploaded a certificate with just BEGIN as text via API, and then proceed to update the keystore table on the MySQL database directly to input the whole cert. It seems to be working, after I uploaded the cert and private key via GUI, I can see that both CPVM and SSVM are being restarted. When I test: - Console is working, using my own domain now. Yay! :) - However, when I try to test downloading a template, it's still showing realhostip.com as the URL to download. I have tried destroying the SSVM and a new SSVM was created, up and running. However, it's still showing realhostip.com when I test again. Anyone knows why it's still referring to realhostip.com for downloading templates? Look at the global settings. There is a domain for the sec storage as well. Maybe restart the mgmt server? Looking forward to your reply, thank you. Cheers. On Sun, Sep 28, 2014 at 12:49 AM, Indra Pramana in...@sg.or.id wrote: Dear all, Apologise for sending quite a lot of emails tonight. Anyone knows if it's safe for me to update the keystore table on the database directly? Since the API call doesn't work. Thank you. On Sun, Sep 28, 2014 at 12:39 AM, Indra Pramana in...@sg.or.id wrote: Only if I key in the certificate as BEGIN, then it seems to be accepting. But of course, the certificate is invalid. uploadcustomcertificateresponse cloud-stack-version=4.2.0 jobid1efe722a-e7c7-4c43-9f6b-67ce860dbe34/jobid /uploadcustomcertificateresponse Is it my browser issue? I have tried using two different browsers: Firefox and Chrome, and both are having the same problem. On Sun, Sep 28, 2014 at 12:36 AM, Indra Pramana in...@sg.or.id wrote: I tried to key in just BEGIN CERTIFICATE\nEND CERTIFICATE without the - and the content of the certificate itself. Same problem persists, it says parameter certificate is invalid, contains illegal ASCII non-printable characters. uploadcustomcertificateresponse cloud-stack-version=4.2.0 errorcode431/errorcode cserrorcode/cserrorcode errortext Received value BEGIN CERTIFICATE END CERTIFICATE for parameter certificate is invalid, contains illegal ASCII non-printable characters /errortext /uploadcustomcertificateresponse Seems the issue was not actually on the certificate itself, but may be on the API call handler? Any advice is greatly appreciated. On Sat, Sep 27, 2014 at 11:35 PM, Indra Pramana in...@sg.or.id wrote: Hi Amogh and all, To add, I am using RapidSSL and I got the root and intermediate CAs from here: https://knowledge.rapidssl.com/support/ssl-certificate-support/index?page=contentactp=CROSSLINKid=SO26457 I have ensured that the encoding is done correctly, but still there's issue when I tried to upload it. Is it because I am still using version 4.2.0, may be there's a different method on how to upload? Error messages: uploadcustomcertificateresponse cloud-stack-version=4.2.0 errorcode431/errorcode cserrorcode/cserrorcode errortext Received value -BEGIN CERTIFICATE- MIIDfTCCAuagAwIBAgIDErvmMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVT MRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0 aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwNTIxMDQwMDAwWhcNMTgwODIxMDQwMDAw WjBCMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEbMBkGA1UE
Re: Unable to upload SSL certificate for realhostip replacement
Hi, For the encoding, in your case it was the space character causing the issue - it should be replaced by %20. The correct encoding would be (hoping mail clients don't screw up the blob): -BEGIN%20CERTIFICATE-%0AMIIDfTCCAuagAwIBAgIDErvmMA0GCSqGSIb3DQEBBQU AME4xCzAJBgNVBAYTAlVT%0AMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFN lY3VyZSBDZXJ0%0AaWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwNTIxMDQwMDAwWhcNMTgwODIxMDQ wMDAw%0AWjBCMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEbMBkGA1UE%0A AxMSR2VvVHJ1c3QgR2xvYmFsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB%0ACgKCAQEA 2swYYzD99BcjGlZ%2BW988bDjkcbd4kdS8odhM%2BKhDtgPpTSEHCIjaWC9m%0AOSm9BXiLnTjo BbdqfnGk5sRgprDvgOSJKA%2BeJdbtg%2FOtppHHmMlCGDUUna2YRpIu%0AT8rxh0PBFpVXLVDv iS2Aelet8u5fa9IAjbkU%2BBQVNdnARqN7csiRv8lVK83Qlz6c%0AJmTM386DGXHKTubU1XupGc 1V3sjs0l44U%2BVcT4wt%2FlAjNvxm5suOpDkZALeVAjmR%0ACw7%2BOC7RHQWa9k0%2Bbw8HHa 8sHo9gOeL6NlMTOdReJivbPagUvTLrGAMoUgRx5asz%0APeE4uwc2hGKceeoWMPRfwCvocWvk%2 BQIDAQABo4HwMIHtMB8GA1UdIwQYMBaAFEjm%0AaPkr0rKV10fYIyAQTzOYkJ%2FUMB0GA1UdDg QWBBTAephojYn7qwVkDBF9qn1luMrM%0ATjAPBgNVHRMBAf8EBTADAQH%2FMA4GA1UdDwEB%2Fw QEAwIBBjA6BgNVHR8EMzAxMC%2Bg%0ALaArhilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jcmxz L3NlY3VyZWNhLmNybDBO%0ABgNVHSAERzBFMEMGBFUdIAAwOzA5BggrBgEFBQcCARYtaHR0cHM6 Ly93d3cuZ2Vv%0AdHJ1c3QuY29tL3Jlc291cmNlcy9yZXBvc2l0b3J5MA0GCSqGSIb3DQEBBQUA A4GB%0AAHbhEm5OSxYShjAGsoEIz%2FAIx8dxfmbuwu3UOx%2F%2F8PDITtZDOLC5MH0Y0FWDom rL%0ANhGc6Ehmo21%2FuBPUR%2F6LWlxz%2FK7ZGzIZOKuXNBSqltLroxwUCEm2u%2BWR74M26x 1W%0Ab8ravHNjkOR%2Fez4iyz0H7V84dJzjA1BOoa%2BY7mHyhD8S%0A-END%20CERTIFIC ATE- As for the global parameter, you can set it to something like a few seconds and reset to original value when the URLs have been expired. Thanks Amogh On 9/27/14 10:53 AM, Indra Pramana in...@sg.or.id wrote: Hi Wido, I have changed the value of secstorage.ssl.cert.domain and restart management server, before I start uploading all the certificates. I found this article, which might be related to the problem: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Troubleshooting+-+u ploading+custom+domain+certificate+instead+of+using+realhostip.com *Specific Issues seen* 1. Download urls point to the old domain. 1. Reduce the expiration duration of the urls by changing global config extract.url.expiration.interval 2. And change the frequency for cleanup thread through extract.url.cleanup.interval restart MS. 3. Wait for the cleanup thread duration and try downloading again. See whether the url is deleted. 4. DB tables to check (don¹t recommend but worst case) Version 4.2 upload table persists url. Entry is hard deleted on expiration of url. Version = 4.2 template_store_ref, download_url is made null on expiration of url. volume_store_ref, entry hard deleted on expiration of url. But I'm not too sure what is the recommended values I need to set for extract.url.expiration.interval and extract.url.cleanup.interval. Any advise? Thank you. On Sun, Sep 28, 2014 at 1:39 AM, Wido den Hollander w...@widodh.nl wrote: Op 27 sep. 2014 om 19:25 heeft Indra Pramana in...@sg.or.id het volgende geschreven: Dear all, FYI, I managed to complete the tasks and install the certificates. As a workaround to the unable to upload the root/intermediate cert via API issue, I uploaded a certificate with just BEGIN as text via API, and then proceed to update the keystore table on the MySQL database directly to input the whole cert. It seems to be working, after I uploaded the cert and private key via GUI, I can see that both CPVM and SSVM are being restarted. When I test: - Console is working, using my own domain now. Yay! :) - However, when I try to test downloading a template, it's still showing realhostip.com as the URL to download. I have tried destroying the SSVM and a new SSVM was created, up and running. However, it's still showing realhostip.com when I test again. Anyone knows why it's still referring to realhostip.com for downloading templates? Look at the global settings. There is a domain for the sec storage as well. Maybe restart the mgmt server? Looking forward to your reply, thank you. Cheers. On Sun, Sep 28, 2014 at 12:49 AM, Indra Pramana in...@sg.or.id wrote: Dear all, Apologise for sending quite a lot of emails tonight. Anyone knows if it's safe for me to update the keystore table on the database directly? Since the API call doesn't work. Thank you. On Sun, Sep 28, 2014 at 12:39 AM, Indra Pramana in...@sg.or.id wrote: Only if I key in the certificate as BEGIN, then it seems to be accepting. But of course, the certificate is invalid. uploadcustomcertificateresponse cloud-stack-version=4.2.0 jobid1efe722a-e7c7-4c43-9f6b-67ce860dbe34/jobid /uploadcustomcertificateresponse Is it my browser issue? I have tried using two different browsers: Firefox and Chrome, and both
Re: Unable to upload SSL certificate for realhostip replacement
Can you try using http://meyerweb.com/eric/tools/dencoder/ Amogh On 9/22/14 4:36 AM, Indra Pramana in...@sg.or.id wrote: Dear all, I am following the instruction on this documentation to replace realhostip.com with my own domain. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Procedure+to+Replac e+realhostip.com+with+Your+Own+Domain+Name Everything is fine until I need to upload the root certificate via API. I have URL-encoded the certificate using online URL encoder tool such as: http://www.url-encode-decode.com/ However, when I run the API command, the certificate is rejected, saying that it contains illegal ASCII non-printable characters: for parameter certificate is invalid, contains illegal ASCII non-printable characters I have ensured and verified that it only contains generic ASCII text format, no space, symbol etc. Tried using UTF-8, US-ASCII format while encoding, but still cannot work. Any advice is greatly appreciated. Looking forward to your reply, thank you. Cheers.
