I'm having a helluva time reproducing this issue.  Can you describe how you initial built your environment before enabling HTTPS?  Was nova-c-c peered and/or clustered?  Are you sure you were deploying the most recent charm revision /w newest branch changes?  bzr revs 71 and 72 dealt with an issue of the endpoint not reconfiguring after adding clustering, since the original reconfig hooks were not sending all required settings.  Late-enabling HTTPS should be limited to identity-changed, though.

I've just tested again by enabling HTTPS after the entire catalog has been populated by haclustererd services (all endpoints pointing to http://$VIP/etc/).  After nova-c-c has reconfigured its reverse proxying, it flushes the following settings back to KS, compute and quantum:

2013-02-27 15:09:31,482: hook.output@DEBUG: Flushed values for hook 'identity-service-relation-changed' on 'identity-service:27'
    Setting changed: 'ec2_admin_url'=u'https://192.168.77.2:8773/services/Cloud' (was 'http://192.168.77.2:8773/services/Cloud')
    Setting changed: 'ec2_internal_url'=u'https://192.168.77.2:8773/services/Cloud' (was 'http://192.168.77.2:8773/services/Cloud')
    Setting changed: 'ec2_public_url'=u'https://192.168.77.2:8773/services/Cloud' (was 'http://192.168.77.2:8773/services/Cloud')
    Setting changed: 'nova_admin_url'=u'https://192.168.77.2:8774/v1.1/$(tenant_id)s' (was 'http://192.168.77.2:8774/v1.1/$(tenant_id)s')
    Setting changed: 'nova_internal_url'=u'https://192.168.77.2:8774/v1.1/$(tenant_id)s' (was 'http://192.168.77.2:8774/v1.1/$(tenant_id)s')
    Setting changed: 'nova_public_url'=u'https://192.168.77.2:8774/v1.1/$(tenant_id)s' (was 'http://192.168.77.2:8774/v1.1/$(tenant_id)s')
    Setting changed: 'quantum_admin_url'=u'https://192.168.77.2:9696' (was 'http://192.168.77.2:9696')
    Setting changed: 'quantum_internal_url'=u'https://192.168.77.2:9696' (was 'http://192.168.77.2:9696')
    Setting changed: 'quantum_public_url'=u'https://192.168.77.2:9696' (was 'http://192.168.77.2:9696')
    Setting changed: 's3_admin_url'=u'https://192.168.77.2:3333' (was 'http://192.168.77.2:3333')
    Setting changed: 's3_internal_url'=u'https://192.168.77.2:3333' (was 'http://192.168.77.2:3333')
    Setting changed: 's3_public_url'=u'https://192.168.77.2:3333' (was 'http://192.168.77.2:3333')
    Setting changed: u'ca_cert'=u'LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNvekNDQWd5Z0F3SUJBZ0lCQVRBTkJna3Fo\na2lHOXcwQkFRVUZBREJy (was unset) on 'cloud-compute:47'
    Setting changed: 'quantum_url'=u'https://192.168.77.2:9696' (was 'http://192.168.77.2:9696') on 'cloud-compute:47'
    Setting changed: u'ca_cert'=u'LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNvekNDQWd5Z0F3SUJBZ0lCQVRBTkJna3Fo\na2lHOXcwQkFRVUZBREJy (was unset) on 'quantum-network-service:40'
    Setting changed: 'quantum_url'=u'https://192.168.77.2:9696' (was 'http://192.168.77.2:9696') on 'quantum-network-service:40'
2013-02-27 15:09:31,483: hook.executor@DEBUG: Hook complete: /var/lib/juju/units/nova-cloud-controller-
2/charm/hooks/identity-service-relation-changed

If you can test once again, and possibly keep an eye on the nova-c-c leader's charm log, to see what settings change?    The required 'region' and 'service' settings should already be set there from the first, non-HTTPS negiotion.

RE: the second bug/trace, I believe this is due to the nova-c-c service reconfiguring itself to listen HTTPS on the ports, but the catalog not being updated to specify https:// there.