CA certificate installs and works fine, no security issues. I am able to use it for the WordPress admin area and the homepage (root) can be accessed securely no problem. Anytime the server tries to access HTTPS domain.com/anything it returns a 404 page.
I've been teaching myself AWS over the past two weeks and this is the first time I've needed to ask for help. Normally I can find the answers but this time I keep coming up cold. Thanks in advance.
Here are the examples:
https://www.pageantsuppliers.com
https://www.pageantsuppliers.com/cart
Short answer: you have a web server configuration problem.
Long answer: if you save the certificate you get from $ openssl s_client -connect www.pageantsuppliers.com:443 -CAfile startcom-ca.crt (just copy/paste it), the end entity (server certificate) looks OK:
$ openssl x509 -inform PEM -in pageantsuppliers-com.pem -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 984131 (0xf0443)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=IL, O=StartCom Ltd., OU=Secure Digital Certificate Signing, CN=StartCom Class 1 Primary Intermediate Server CA
Validity
Not Before: Mar 9 18:28:34 2014 GMT
Not After : Mar 10 07:32:09 2015 GMT
Subject: description=tq5XRBjgh9USfQ68, C=US, CN=www.pageantsuppliers.com/emailAddress=87f13a43b0ac46298171a954f337671e.protect#whoisguard.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:b6:1a:e0:2c:62:cb:74:f6:8a:82:a5:41:85:29:
fb:f6:68:7a:a1:68:04:ec:ea:fe:fc:a5:44:66:dc:
69:6f:d5:9b:2a:4a:b0:56:00:b9:65:c1:f9:a5:36:
f5:66:03:ee:d7:a3:22:7d:a2:eb:45:ba:28:b5:6d:
66:29:93:4b:a2:a7:21:d8:ca:fe:4f:43:4f:49:72:
10:ee:57:08:d5:27:39:e1:ad:56:9a:7a:24:25:e6:
91:6f:b5:8f:32:fb:3e:fc:30:2d:bd:53:7d:3b:d3:
f0:b7:a6:1f:eb:60:ea:92:37:5e:d9:da:f5:40:5a:
7b:aa:e3:ae:65:60:c0:11:bb:79:4d:08:85:7b:7d:
1d:e6:b3:7a:45:91:12:9f:c1:f4:54:9b:9b:a2:a0:
f5:e9:64:e2:4f:8f:c6:f3:f4:54:73:02:77:4b:d9:
6b:c0:47:84:8f:ea:b4:05:b9:39:0b:1e:f5:37:ee:
90:d6:87:e0:c3:15:56:db:e6:fa:b9:fa:4e:1f:36:
c8:df:c9:e8:3a:63:46:d2:e9:e6:07:67:00:6a:10:
d2:d1:40:19:1a:ac:f5:ef:17:28:73:05:6b:69:d1:
74:a8:7b:2e:92:13:fb:f5:d5:d3:57:a6:b6:9f:94:
34:68:c2:ff:8f:5a:8c:3b:8e:d5:c4:f7:6a:97:54:
a4:97
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Key Encipherment, Key Agreement
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Subject Key Identifier:
DD:18:77:CF:57:39:39:EF:1E:B7:E0:25:09:D2:90:72:83:11:D3:9D
X509v3 Authority Key Identifier:
keyid:EB:42:34:D0:98:B0:AB:9F:F4:1B:6B:08:F7:CC:64:2E:EF:0E:2C:45
X509v3 Subject Alternative Name:
DNS:www.pageantsuppliers.com, DNS:pageantsuppliers.com
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
Policy: 1.3.6.1.4.1.23223.1.2.3
CPS: http://www.startssl.com/policy.pdf
User Notice:
Organization: StartCom Certification Authority
Number: 1
Explicit Text: This certificate was issued according to the Class 1 Validation requirements of the StartCom CA policy, reliance only for the intended purpose in compliance of the relying party obligations.
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl.startssl.com/crt1-crl.crl
Authority Information Access:
OCSP - URI:http://ocsp.startssl.com/sub/class1/server/ca
CA Issuers - URI:http://aia.startssl.com/certs/sub.class1.server.ca.crt
X509v3 Issuer Alternative Name:
URI:http://www.startssl.com/
Signature Algorithm: sha1WithRSAEncryption
42:8e:78:33:a0:76:39:90:9c:53:b8:e7:7a:a4:06:6d:8a:7c:
f4:65:90:87:70:a9:da:b4:19:09:e2:dd:fd:75:39:c8:f8:bf:
d2:de:e7:0f:70:a8:92:71:2c:fe:45:5f:5b:14:e4:9b:80:1f:
54:7b:1a:37:b4:de:b7:fc:c8:d4:c6:7f:07:be:cc:16:cb:82:
08:12:ff:fe:14:cb:ac:64:83:17:a3:a0:f9:e1:97:6f:66:e8:
9b:13:d3:da:e5:be:c7:43:14:18:6d:bc:76:55:00:c4:8c:8e:
1e:0f:a1:21:46:e3:60:db:5a:1d:7f:61:49:43:55:d7:b6:1c:
af:b2:84:f2:e5:e8:f9:e4:db:ab:b6:38:26:74:cb:8d:69:f6:
9c:0b:ac:fd:bf:9b:c5:3b:3b:2c:16:72:69:7f:7e:7d:7c:37:
bd:f1:e1:83:5e:42:ed:9c:0e:c3:b5:e1:6d:f3:91:ec:07:ff:
7d:12:4c:37:73:5d:9f:be:d2:55:8e:ef:c5:48:3d:7d:d5:cb:
0c:e1:75:ef:dd:0c:8e:46:50:0a:9a:3c:72:28:8d:c0:31:df:
65:06:44:e0:af:3f:0f:7e:de:04:10:be:a0:e9:b9:c6:03:b8:
38:fe:b1:a7:fb:af:b7:6f:82:10:7a:a6:38:50:07:9e:5b:19:
e1:a6:bf:95
The issuer is StartCom Class 1 Primary Intermediate Server CA, which should be OK. And StartCom Class 1 Primary Intermediate Server CA's issuer is StartCom Certification Authority, which should also be OK.
However, when issuing a GET:
$ echo "GET / HTTP/1.1" | openssl s_client -connect www.pageantsuppliers.com:443 -CAfile ca-bundle.pem -servername www.pageantsuppliers.com
CONNECTED(00000003)
depth=3 C = IL, O = StartCom Ltd., CN = StartCom Certification Authority G2
verify return:1
depth=2 C = IL, O = StartCom Ltd., OU = Secure Digital Certificate Signing, CN = StartCom Certification Authority
verify return:1
depth=1 C = IL, O = StartCom Ltd., OU = Secure Digital Certificate Signing, CN = StartCom Class 1 Primary Intermediate Server CA
verify return:1
depth=0 description = tq5XRBjgh9USfQ68, C = US, CN = www.pageantsuppliers.com, emailAddress = 87f13a43b0ac46298171a954f337671e.protect#whoisguard.com
verify return:1
---
...
Start Time: 1394991510
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
DONE
It appears there is no web server serving content on that port. The DONE above should be replaced with raw HTML because s_client simply prints what it receives. You can also add -pause -ign_eof to keep the connection open, but that's not your problem (see s_client(1) docs).
You have a web server configuration problem.
I ended up hiring someone on freelancer to figure it out for me. Well worth the $39. Here is what he said so that others can share in the knowledge.
From roonex on freelancer:
I edited this file: /etc/httpd/conf.d/ssl.conf and on the end of just
before closing tag it I added this code:
<Directory /var/zpanel/hostdata/zadmin/public_html>
AllowOverride none
Order Allow,Deny
Allow from all
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</Directory>
The problem was that for ssl you have to tell the virtual host to use
same folder for http and https, in plesk or cpanel you have to check
only one checkbox to do this, but for zpanel you have to do this
change in the ssl.conf
After this just restart the apache and it will be fixed
Related
I'm trying to create a solution based on Azure AKS Baseline.
I have and AKS with Nginx Ingress Controller and Azure Gateway V2.
I need to make a conversation between Azure Gateway V2 and Nginx Ingress controller secured, by using certificates that were generated by Azure Key Vault.
In the backend health probe I have this error:
The root certificate of the server certificate used by the backend does not match the trusted root certificate added to the application gateway. Ensure that you add the correct root certificate to whitelist the backend
3 certificates were added to the KeyVault: root, intermediate and vl.aks-ingress.mydomain.com
intermediate certificate's CSR was signed by root private key and merged to key vault.
domain's CSR was signed by intermediate private key and merged to key vault.
That's how I signed intermediate and domain certificates:
$signerCertSecret = Get-AzKeyVaultSecret -VaultName $KeyVaultName -Name $SignerCertificateName
$signerCertsecretByte = [Convert]::FromBase64String(($signerCertSecret.SecretValue | ConvertFrom-SecureString -AsPlainText))
$signerCertPfxFilePath = New-TemporaryFile
[System.IO.File]::WriteAllBytes($signerCertPfxFilePath, $signerCertsecretByte)
$policy = New-AzKeyVaultCertificatePolicy -SecretContentType "application/x-pkcs12" `
-SubjectName "CN=$Subject" `
-IssuerName "Unknown" `
-ValidityInMonths 60 `
-ReuseKeyOnRenewal
$_ = Add-AzKeyVaultCertificate -VaultName $KeyVaultName -Name $CertificateName -CertificatePolicy $policy
$csrTempFile = New-TemporaryFile
$certCsr = '-----BEGIN CERTIFICATE REQUEST-----' + `
[Environment]::NewLine + `
(Get-AzKeyVaultCertificateOperation -VaultName $keyVaultName -Name $CertificateName).CertificateSigningRequest + `
[Environment]::NewLine + `
'-----END CERTIFICATE REQUEST-----'
[System.IO.File]::WriteAllText($csrTempFile, $certCsr)
$signerKeyFile = New-TemporaryFile
$signerCertFile = New-TemporaryFile
$pass = "pass123"
openssl pkcs12 -in $signerCertPfxFilePath -nocerts -out $signerKeyFile -passin pass: -passout pass:$pass
openssl pkcs12 -in $signerCertPfxFilePath -clcerts -nokeys -out $signerCertFile -passin pass:
$signedNewCert = New-TemporaryFile
openssl x509 -req -in $csrTempFile -days 3650 -CA $signerCertFile -CAkey $signerKeyFile -CAcreateserial -out $signedNewCert -passin pass:$pass
az keyvault certificate pending merge --vault-name $KeyVaultName --name $CertificateName --file $signedNewCert
After that, I've imported everything to my Windows machine and export the full chain (I didn't find any way to do it automatically via Key Vault). This full chain certificates I've added to the keyvault as a secret. Then this secret was added as secret to the AKS. To test that everything is ok with nginx ingress, I've added a Windows VM to the same network. Inside AKS I've added some super small server and requested it from browser in my VM. Browser cried that certificate is unsafe, but I got the full chain:
Then I've downloaded ROOT CA cer from the keyvault and added it to the gateway.
My understanding is that everything should work properly after that.
But I'm still getting a "root certificate wrong error".
I will appreciate any help or advice, cause I've already waste a week for that and don't have any significant progress.
Thanks in advance!
Problem Statement:
I've wanted to change the SSL certificate, because I've changed my server so I had to create a new CSR with the different name as discuss in the following question with this command. And generated the Privatekey and CSR.
$ openssl req -new -newkey rsa:2048 -nodes -keyout example_new.key -out example_new.csr
Then I'd paste the CSR to Re-Key in Godaddy portal and received certificate from Godaddy and then i renamed it to the following as per best practises.
example.com.crt
intermediate.crt
example.com.pem
And then I've concatenated the certificate with signing certificate in right order as discussed in this answer.
$ cat example.com.crt intermediate.crt > bundle_chained.crt
Exception:
Getting following exception while restarting Nginx.
$ sudo nginx -t
nginx: [emerg] SSL_CTX_use_PrivateKey_file("/path/example_new.key") failed (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch)
nginx: configuration file /etc/nginx/nginx.conf test failed
Here's what I tested:
The certificate and private key has no trailing spaces.
I checked the nginx.conf and the directives are pointing to the
correct private key and certificate.
I've checked md5 hashed of the key and bundle_chained
$ openssl x509 -noout -modulus -in bundle_chained.crt | openssl md5
(stdin)= d91144b76e2fa292e9aee71f10ac8b63
$ openssl rsa -noout -modulus -in example.key | openssl md5
(stdin)= a4773e7fa31e0bdc7edad15ee5412d3e
Note: Md5 hash are not matching
Checked bundle_chained.crt using following and figure out that it doesn't look like my as I've specified Maharashtra ST and it is showing Arizona which is my CA.
$ openssl x509 -noout -text -in bundle_chained.crt
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
8d:a1:9d:55:8c:d8:as:45
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", OU = http://certs.godaddy.com/repository/, CN = Go Daddy Secure Certificate Authority - G2
Validity
Not Before: Aug 20 11:54:25 2020 GMT
Not After : Aug 19 10:00:10 2022 GMT
Subject: OU = Domain Control Validated, CN = example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
....
.....
Note: Please note that it did showing CN correct as example.com in my case.
Thank you for your help. :)
and thank you for reading. I know this question has been asked many times - I've read a ton of different answers, and have tried most of them. None of them have worked so far. I'm pretty new to using postfix and appreciate any assistance you can provide.
I'm using Proxmox 6.1, on Debian buster. I'm attempting to use the email function for failed backups. My domain is using Gsuite mail. I have setup the SMTP relay with both my ipv4 and ipv6 public addresses, and I have verified the credentials are correct and generated new .db each time I made a change.
My sasl_passwd
smtp-relay.gmail.com:587 root#mydomain.com:password
My main.cf (domain & ip have been edited)
# See /usr/share/postfix/main.cf.dist for a commented, more complete version
#myhostname=pve.myisp (auto generated)
myhostname = mydomain.com
#G-Suite relay test
relayhost = smtp-relay.gmail.com:587
# Use tls
smtp_use_tls = yes
smtp_tls_security_level = encrypt
tls_random_source = dev:/dev/urandom
# Use sasl when authenticating to foreign SMTP servers
smtp_sasl_auth_enable = yes
# Path to password map file
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
# List of CAs to trust when verifying server certificate
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
# Eliminates default security options which are imcompatible with gmail
smtp_sasl_security_options = noanonymous
smtp_sasl_mechanism_filter = plain
compatibility_level = 2
Error logs:
Apr 30 16:45:52 pve postfix/qmgr[34586]: 4B3AD320C9A: from=<root#mydomain.com>, size=396, nrcpt=1 (queue active)
Apr 30 16:45:54 pve postfix/smtp[34617]: 4B3AD320C9A: SASL authentication failed; server smtp-relay.gmail.com[74.125.30.28] said: 535-5.7.8 Username and Password not accepted. Learn more at?535 5.7.8 https://support.google.com/mail/?p=BadCredentials m33sm110720uad.2 - gsmtp
Apr 30 16:45:54 pve postfix/smtp[34617]: 4B3AD320C9A: to=<mypersonalemail#gmail.com>, relay=smtp-relay.gmail.com[2607:f8b0:4003:c0b::1c]:587, delay=2.6, delays=0.05/0.06/2.4/0, dsn=4.7.8, status=deferred (SASL authentication failed; server smtp-relay.gmail.com[2607:f8b0:4003:c0b::1c] said: 535-5.7.8 Username and Password not accepted. Learn more at?535 5.7.8 https://support.google.com/mail/?p=BadCredentials v7sm169048ooo.20 - gsmtp)
I managed to solve my issue.
Ignore any & all gsuite documentation, and use [smtp.gmail.com]:587 instead of smtp-relay.gmail.com:587
I've got an application that's getting SSL warnings on Chrome for Android and it turns out I need to add my CA Bundle from RapidSSL. I don't see a way to do this using Laravel Forge. How can I accomplish this?
My nginx config was auto-generated by Laravel Forge and looks like this:
# FORGE SSL (DO NOT REMOVE!)
ssl on;
ssl_certificate /etc/nginx/ssl/mydomain.com/1646/server.crt;
ssl_certificate_key /etc/nginx/ssl/mydomain.com/1646/server.key;
Status before: untrusted page
I had the same issue with a comodo certificate from https://cheapsslsecurity.com/. At first I installed only the domain specific certificate via the laravel forge webinterface (www_timtimer_at.crt) which resulted in an untrusted page.
Stumbling upon the answer of #Citizen and the post Nginx not serving intermediate certificate helped me to fix it. See this post also for debugging instructions.
How to fix the problem
SSL-Status
Use openssl s_client -connect www.timtimer.at:443 to check the certificate chain. (As am I am using Windows I just used the git bash to use this command). It should be a real chain like the following (s=subject, i=issuer). So you always have a subject with an issuer. This issuer should be the next subject which is issued by another authority and so on. The last subject is itselfs issuer.
At first my certificate chain looked like the following:
Certificate chain
0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=www.timtimer.at
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
The Verify return code was: 21 (unable to verify the first certificate).
Solution
Check your server configuration file (I am using Laravel forge with nginx, so my file would be /etc/nginx/sites-available/default to get the location of the certificate you are using. Look out for the following section
# FORGE SSL (DO NOT REMOVE!)
ssl_certificate /etc/nginx/ssl/default/2658/server.crt;
ssl_certificate_key /etc/nginx/ssl/default/2658/server.key;
So in my case the certificate is stored in /etc/nginx/ssl/default/2658/server.crt. Now edit this file and make sure you put all the needed certificates in there. I added the content of the certificates from the zip-file in the following order:
www_timtimer_at.crt
COMODORSAAddTrustCA.crt
COMODORSADomainValidationSecureServerCA.crt
AddTrustExternalCARoot.crt
The file should look like like the following
-----BEGIN CERTIFICATE-----
... (www_timtimer_at.crt)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
... (COMODORSAAddTrustCA.crt)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
... (COMODORSADomainValidationSecureServerCA.crt)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
... (AddTrustExternalCARoot.crt)
-----END CERTIFICATE-----
After a /etc/init.d/nginx restart everything looked good.
I received the following certificate chain after executing openssl s_client -connect www.timtimer.at:443:
Certificate chain
0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=www.timtimer.at
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
3 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
The Verify return code was: 19 (self signed certificate in certificate chain).
Ok, so I solved this problem by doing the following:
Download the RapidSSL CA bundle:
https://knowledge.rapidssl.com/support/ssl-certificate-support/index?page=content&id=AR1549
Paste it below my certificate in a text file.
https://www.digicert.com/ssl-support/pem-ssl-creation.htm
Pasted the three certs in one into Laravel forge when it asks for my certificate.
And it worked!
i'm trying to automate the login of the UK's data archive service. that website is obviously trustworthy. unfortunately, both RCurl and httr break at SSL verification. my web browser doesn't give any sort of warning. i can work around the issue by using ssl.verifypeer = FALSE in RCurl but i'd like to understand what's going on?
# breaks
library(httr)
GET( "https://www.esds.ac.uk/secure/UKDSRegister_start.asp" )
# breaks
library(RCurl)
cert <- system.file("CurlSSL/cacert.pem", package = "RCurl")
getURL("https://www.esds.ac.uk/secure/UKDSRegister_start.asp",cainfo = cert)
# works
library(RCurl)
getURL(
"https://www.esds.ac.uk/secure/UKDSRegister_start.asp" ,
.opts = list(ssl.verifypeer = FALSE)
) # note: use list(ssl.verifypeer = FALSE,followlocation=TRUE) to see content
TL;DR
Get the TERENA SSL CA PEM file from TERENA's repository of trusted certificates and use this file as your cainfo parameter.
EDIT: You might need to add two lines to the beginning of that file. The code works for me using the following TERENA.pem file:
TERENA
======
-----BEGIN CERTIFICATE-----
MIIEmDCCA4CgAwIBAgIQS8gUAy8H+mqk8Nop32F5ujANBgkqhkiG9w0BAQUFADCB
lzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2Ug
Q2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExho
dHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xHzAdBgNVBAMTFlVUTi1VU0VSRmlyc3Qt
SGFyZHdhcmUwHhcNMDkwNTE4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjA2MQswCQYD
VQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRYwFAYDVQQDEw1URVJFTkEgU1NMIENB
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw+NIxC9cwcupmf0booNd
ij2tOtDipEMfTQ7+NSUwpWkbxOjlwY9UfuFqoppcXN49/ALOlrhfj4NbzGBAkPjk
tjolnF8UUeyx56+eUKExVccCvaxSin81joL6hK0V/qJ/gxA6VVOULAEWdJRUYyij
8lspPZSIgCDiFFkhGbSkmOFg5vLrooCDQ+CtaPN5GYtoQ1E/iptBhQw1jF218bbl
p8ODtWsjb9Sl61DllPFKX+4nSxQSFSRMDc9ijbcAIa06Mg9YC18em9HfnY6pGTVQ
L0GprTvG4EWyUzl/Ib8iGodcNK5Sbwd9ogtOnyt5pn0T3fV/g3wvWl13eHiRoBS/
fQIDAQABo4IBPjCCATowHwYDVR0jBBgwFoAUoXJfJhsomEOVXQc31YWWnUvSw0Uw
HQYDVR0OBBYEFAy9k2gM896ro0lrKzdXR+qQ47ntMA4GA1UdDwEB/wQEAwIBBjAS
BgNVHRMBAf8ECDAGAQH/AgEAMBgGA1UdIAQRMA8wDQYLKwYBBAGyMQECAh0wRAYD
VR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VUTi1VU0VS
Rmlyc3QtSGFyZHdhcmUuY3JsMHQGCCsGAQUFBwEBBGgwZjA9BggrBgEFBQcwAoYx
aHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0U2VydmVyX0NBLmNy
dDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG
9w0BAQUFAAOCAQEATiPuSJz2hYtxxApuc5NywDqOgIrZs8qy1AGcKM/yXA4hRJML
thoh45gBlA5nSYEevj0NTmDa76AxTpXv8916WoIgQ7ahY0OzUGlDYktWYrA0irkT
Q1mT7BR5iPNIk+idyfqHcgxrVqDDFY1opYcfcS3mWm08aXFABFXcoEOUIEU4eNe9
itg5xt8Jt1qaqQO4KBB4zb8BG1oRPjj02Bs0ec8z0gH9rJjNbUcRkEy7uVvYcOfV
r7bMxIbmdcCeKbYrDyqlaQIN4+mitF3A884saoU4dmHGSYKrUbOCprlBmCiY+2v+
ihb/MX5UR6g83EMmqZsFt57ANEORMNQywxFa4Q==
-----END CERTIFICATE-----
Why?
The GET method of httr uses RCurl::curlPerform internally, as does RCurl::getURL, so the observed behavior is not surprising. The curl command-line tools with the "verbose" switch -v gives the following additional hints:
$ curl -v "https://www.esds.ac.uk/secure/UKDSRegister_start.asp"
* About to connect() to www.esds.ac.uk port 443 (#0)
* Trying 155.245.69.4...
* Connected to www.esds.ac.uk (155.245.69.4) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
The link in the above error message contains, at enumeration item 3, instruction on obtaining the server's certificate:
$ openssl s_client -connect "www.esds.ac.uk:443"
CONNECTED(00000003)
depth=0 C = GB, ST = Essex, L = Colchester, O = University of Essex, OU = UK Data Archive, CN = www.esds.ac.uk
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = GB, ST = Essex, L = Colchester, O = University of Essex, OU = UK Data Archive, CN = www.esds.ac.uk
verify error:num=27:certificate not trusted
verify return:1
depth=0 C = GB, ST = Essex, L = Colchester, O = University of Essex, OU = UK Data Archive, CN = www.esds.ac.uk
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/C=GB/ST=Essex/L=Colchester/O=University of Essex/OU=UK Data Archive/CN=www.esds.ac.uk
i:/C=NL/O=TERENA/CN=TERENA SSL CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEIzCCAwugAwIBAgIQO9FPWbAYKDAuFHq61U3gDDANBgkqhkiG9w0BAQUFADA2
MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRYwFAYDVQQDEw1URVJFTkEg
U1NMIENBMB4XDTEwMTIwNjAwMDAwMFoXDTEzMTIwNTIzNTk1OVowgYMxCzAJBgNV
......
To me, this reads as if the certificate is not trusted. A quick search for "terena ssl root certificate" found this website of the University of Helsinki which reads:
Unfortunately root certificates of these authorities are not always present in devices in use, instead, we need to install those root certificates ourselves.
This site also contains a link to the certificate repository.